菜单
面向人的结构化方案 skill（活动、培训、工作坊、合作提案、项目计划）。输入是已由 grill 确认的需求与边界，产物是推动读者决策或行动的正式方案；信息缺口涉及用户取舍时返回 grill，不在 frame 内追问确认。具体软件产品需求规格归 507-prd。Use when user mentions 写方案, 写计划, 活动方案, 培训方案, 工作坊方案, 合作提案, 项目计划, 结构化文档, 正式提案, frame, proposal, workshop plan, partnership proposal, project plan, brief.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Git 提交：在用户明确要求提交时，轻量安全复核变更、精确暂存、运行相关验证并创建真实 Conventional Commit；只做本地提交，推送与对外发布由 507-release 承接。Use when user says commit, 提交, 提交一下, 提交这些改动, 提交代码, Git 提交, commit 一下, 生成并执行提交, 准备提交, 存个档。
对外发布：在用户明确要求发布、推送或发版时，定版本号、打 tag、推送远端，并按项目实际探测的发布渠道（npm、GitHub Release）发布。每个不可逆对外动作执行前都向用户显式确认。Use when user says release, publish, push, 发版, 发布, 推送, 发包, 打 tag, 升版本, 升级版本号, 发新版本, 上线, 发到 npm, 发 GitHub Release。默认只做用户明确点名的对外动作，不自动扩到全部渠道。
根因修复：已明确存在 bug、报错、崩溃、异常、回归或合并冲突时，先建立可重复反馈环，再以最小改动修复根因并验证。Use when user says fix, 修一下, 修 bug, 报错了, 崩了, 跑挂了, 有 bug, 修复报错, 合并冲突, 修复冲突, 修不通, debugging, error, crash, regression.
维护项目地图：以当前代码为证据，建立或校准 README、doc 组织、目录职责、入口与上下游，只修改地图文档。Use when user says map, project map, 梳理项目结构, 项目结构, 更新 README, 补 README, 校准 README, 整理 doc, 整理结构, 文档地图, 目录职责, 分层 README.
交付审查：围绕明确的 commit、branch、diff 或路径检查 Standards、Spec 与 Code Quality，只报告问题、证据和路由。Use when user says review this change, code review, review 一下, 检查, 审查, 审查改动, 审查这次改动, 检查提交, 检查分支, 过一遍代码, 把关, 需求符合度, 交付审查. 不用于主动寻找全库架构机会。
在保持公开契约与可观察行为不变的前提下，对指定代码范围或 507-inspect 报告逐项建立证据、修改并验证。可深入内部模块、抽象与接缝；若需要行为变化则停止并路由到需求实施。Use when user mentions simplify, simplify code, 简化, 简化代码, 行为不变重构, 内部简化, 按报告修改, 处理 inspect 报告, 局部重构, 降低复杂度, 收敛架构摩擦。
| name | 507-frame |
| description | 面向人的结构化方案 skill（活动、培训、工作坊、合作提案、项目计划）。输入是已由 grill 确认的需求与边界，产物是推动读者决策或行动的正式方案；信息缺口涉及用户取舍时返回 grill，不在 frame 内追问确认。具体软件产品需求规格归 507-prd。Use when user mentions 写方案, 写计划, 活动方案, 培训方案, 工作坊方案, 合作提案, 项目计划, 结构化文档, 正式提案, frame, proposal, workshop plan, partnership proposal, project plan, brief. |
这个 skill 用来辅助用户起草结构化的方案、计划或文档。
活动方案、培训方案、工作坊方案、合作提案、项目计划——任何"有明确结构、面向特定受众、用于推动决策或行动"的方案/计划/文档。
507-prd）507-grill）507-frame 消费已经确认的需求，不承担确认本身。动笔前先检查目标受众、目的、范围、关键约束和成功标准：
507-grill，确认后再继续；确认完成后更新同一份文档为当前真相源，不保留貌似正式、实际已过期的平行方案。
如果用户要写的是现场分享稿、PPT 逐页稿、课程讲稿、企业培训演讲稿，尤其是案例型分享风格，优先使用 507-stage。
507-frame 负责正式方案和结构化文档；507-stage 负责现场讲述和 PPT 内容风格。
读起来像"认真在做一件事"，不像"想推销你"，也不像"内部在讨论"。
反面例（AI 风格的段落）：
在 AI 时代浪潮下，我们深入探讨 AI 如何赋能传统行业，致力于打造一站式、全链路的 AI 升级解决方案。我们的核心团队深耕多年，构建了从底层逻辑到应用层的完整闭环。
正面例（同样的内容用克制的方式写）：
这次要做的是帮 B 端客户把已经用上的 AI 工具整合成完整工作流。先做一个 1.5-2 小时的小范围工作坊，挑 10 位老板，把每家的工作流现场拆解，落地后再对接 1v1 诊断和陪跑。
这 7 条来自一次完整的演讲稿 / PPT 打磨，适用于方案、计划、课程稿和企业分享内容。
先给事实，不先给观点。
不要先写：
今天我们将系统探讨 AI 如何进入企业工作流。
更好：
这是一家租车公司。它的车会放到多个平台上出租。AI 已经可以做查价前置动作。
优先按这个顺序写：
案例里发生了什么
这说明什么
下一步怎么做
示例：
AI 已经能查价。
但查价只是流程里的一个点。
下一步是看它能不能接住还车、维修、投诉、结算。
比喻要帮助理解，不要抢主题。
可用比喻：
不要写：
实现业务流程自动化闭环，构建企业级 AI 工作台。
更好：
AI 读表。AI 写回表。飞书自动推送。人处理确认。结果再回到表里。
不要一页里同时讲背景、问题、方法、边界、结论。
更好的台阶是：
AI 已经接了查价
查价只是一个点
AI 接不住散信息
所以要一张表
表要有字段
字段能触发动作
不要一上来就把大结论压给读者。
先让读者看到事实变化，再让结论自然长出来。
方案可以正式，但不要写成 AI 宣传稿。
更像自然口语的句子：
这一步已经跑起来了。但它现在只是流程里的一个点。
不要写：
该案例体现了 AI 在业务流程中的初步落地价值。
| 原则 | 含义 | 反例 | 正例 |
|---|---|---|---|
| 具体而非抽象 | 用数字/动作/对象替代形容词 | "小规模、高质量" | "10 位左右，邀约制" |
| 主动而非被动 | 主语执行动作 | "培训由团队交付" | "团队交付培训" |
| 正面而非双重否定 | "我们做 X" 而非"我们不做 Y" | "现场不做完整改造" | "现场做诊断和思路讲解" |
| 删除冗词 | 砍"内部对话""作为""与此同时""考虑到" | "考虑到活动的定位，我们认为 3 段方法是比较合适的" | "用 3 段方法" |
| 相关信息紧邻 | 同一段内的"做什么/为什么"靠近，不要打散 | "老板需要做一件事。（中间隔了 5 段其他内容）这件事就是带 SOP 来……" | "老板带 SOP 来；现场拆解" |
| 关键信息放末位 | 重点放结尾——读者扫到结尾就能抓到核心 | "老板带走的是……怎么改（中间插了 8 行修饰）" | "老板带走 1 件事：怎么改" |
Puffery 形容词：划时代、里程碑式、标志性、典范性、重中之重、至关重要、不可或缺、举足轻重、卓越、杰出、非凡
空话短语：致力于、旨在、力图、不断推动、持续赋能、深入贯彻、全面落实、全方位、立体化、多维度
营销/AI 高频词：赋能、助力、引领、打造、构建、矩阵、体系、生态、闭环、链路、赛道、底层逻辑、深耕、颠覆、变革、转型、升级、智能化、智慧化、数字化、定制化、一站式、全链路、端到端、突破性、开创性、无缝、稳健
AI 高频动词：深入探讨、深度解析、全面剖析、系统梳理、聚焦、发力
AI 句式：
| 不要做 | 原因 | 反例 |
|---|---|---|
| 不挂来源 | 方案是独立的 | "本次方法论基于《XX 课程》第 2、5、8 课" |
| 不写议论稿 | 方案是陈述不是讨论 | "我们认为，本次沙龙的核心价值在于……" |
| 不写未聊透的内容 | 没确认的别写 | "风险控制（5 列表格：风险/触发/预防/兜底/责任方）"——没聊透就不写 |
| 不包太多 | 章节数按规模灵活 | 2 小时活动不写 11 章 |
| 不写 v1/v2 叙事 | 方案不是迭代记录 | "v1 我们考虑过 99 元，v2 改成 199" |
| 不写案例叙事 | 方案不是故事 | "在和某人讨论的过程中，我们意识到……" |
| 不写工具用法清单 | 内容是工作流不是工具科普 | "朋友圈文案生成、客户跟进话术、爆款标题公式……" |
| 不写"对企业的价值"+"对学员的价值"两栏 | 在具体场景里人就是企业本身 | 拆分只在泛指场景下有意义 |
| 不写"联合发起人" | 角色包装太重 | 直接说"案例合作方 + 社群入口" |
| 不写内部决策过程 | 方案不是工作日志 | "我们讨论后认为…" → 直接写"做 X" |
| 不用否定句/辩护句/弱化词 | 否定句暴露不自信，读者读到像在自我辩护 | 见下方「肯定句原则」 |
方案里只要出现否定句、辩护导语、让步句、弱化词，就是在暴露不自信。读者读到"不是…是…""这是一次低成本的尝试"，会觉得你在自我辩护、在撇清。
只在真的不确定时才用不确定语气。其余一律肯定句。
禁止形态：
| 形态 | 反例 | 正例 |
|---|---|---|
| 否定定义 | "这不是把需求外包成产品" | 删（概览表已说清事实） |
| 辩护导语 | "这是一次低成本的验证尝试…" | 删，直接进事实 |
| 弱化词 | "尝试性方案""不保证完整度" | "方案""属验证级原型" |
| 不确定语气 | "要不要做成…看路演结果再定" | "是否深化，由企业决定" |
| 括号补丁 | "一个懂业务的人（不必是技术）" | "一个懂业务的人" |
| 堆叠否定 | "不出人开发、不组织、不到场" | 删（上面表格已说清） |
边界信息要保留，但改肯定陈述。 需要让读者知道"验证级、非成品、深化另谈"这类边界，不能丢，只是从否定/辩护改成定义式陈述：把"不保证商用完整度"写成"属验证级原型"。
清不干净的信号： 如果某段话删掉后信息没丢，说明它本来就是辩护；如果删掉后读者会误解边界，就改成肯定陈述保留下来。
| 元素 | 立场 |
|---|---|
| 装饰性 emoji（每段一个小表情） | 不用 |
| 频繁加粗（每句都加粗） | 克制，只在关键判断处加粗 |
| 装饰性 callout 框（"💡注意：…""🔥亮点：…"） | 不用 |
| 表格里 emoji 表头 | 不用 |
| 表格本身（信息密度高时用） | 保留 |
| 章节序号（一、二、三） | 保留 |
| 关键判断处的结构性 callout | 保留（不是装饰性的） |
| 标题中的日期（"｜2026-06-05"） | 砍掉 |
先读 507-grill 的累积共识、用户提供的案例/参考文档和项目既有规则。frame 只检查输入是否足够写，不重新开启一轮访谈：
507-grill；交付前自己问自己三个问题：
507-grill；方案获批并需要具体产品规格时进入 507-prd；需要拆追踪任务时进入 507-issue；需要现场讲述时进入 507-stage；方案本身即交付时直接结束。