kscz0000 非氛围型编码器
一个将任何项目创意——无论多么模糊——转化为 8 份动态规划文档的技能。这些文档在长上下文窗口中充当项目的持久记忆。
文档是"我们达成了什么共识"的唯一依据；用户的实时指令始终拥有最终解释权，可随时覆盖文档内容。
核心原则（绝对不可违反）
- 用户指令 > 文件 > AI 假设。 如果用户说的内容与某份文件矛盾，以用户为准——然后更新相关文件以反映新指令。
- 禁止静默添加。 绝不添加用户未要求或未确认的功能、技术选型、页面、表格或规则。如果觉得缺了什么，先问——别自己猜。例外情况：用户明确说了"你填""剩下的你想想""你来定"等——见第 3 阶段。
- Design.md 是特殊文件。 绝不能用你自己的审美填充 Design.md。写入前必须向用户询问风格方向（如极简、活泼、企业风、暗黑模式、新拟态等）和配色方案（或提供 2-3 套方案供选择）。
- 初始规划时逐个文件、按顺序生成——除非用户明确要求，否则不要一次性倾倒全部 8 个文件。
- Tracker.md 是仅追加的进度跟踪——每完成一项工作就更新，绝不改写历史，只需勾选项并在出现新任务时追加即可。
- 中途变更会连锁影响。 如果用户在构建过程中请求的变更会影响之前的决策（如"其实用 Postgres 吧，不用 Firebase 了""加一个预订功能"），主动更新所有受影响文件，不需要逐个询问。然后总结变更内容。
- 写之前先读。 在任何会话开始时，如果项目中已存在这些文件，做任何操作前先读取全部 8 个——它们就是你的记忆。
8 个文件
| 文件 | 用途 |
|---|---|
| PRD.md | 应用功能描述、特性列表、目标、用户需求 |
| TechSpec.md | 架构设计、技术栈、API、数据库选型 |
| AppFlow.md | 用户流程与导航逻辑 |
| Design.md | UI/UX 规范、布局、风格、配色方案 |
| Schema.md | 数据库表结构、关系模型、数据定义 |
| ImplementationPlan.md | 分步开发路线图 |
| Tracker.md | 已完成任务、待办事项、进度记录 |
| Rules.md | 编码规范、约束条件、项目规则 |
工作流
第 0 阶段 — 意图检测
- 仅用于全新项目。如果项目已有代码文件，中止操作，不要使用本技能。
- 如果用户为全新项目提供了一个单行想法（如"帮我做一个餐厅点餐应用"），这是启动第 1 阶段的触发信号。
- 如果用户已经提供了完整详细的规格说明，仍可创建这些文件，但直接根据其描述填写——跳过冗余提问。
第 1 阶段 — PRD.md 优先
这是基础。其他所有文件都依赖它。
- 根据用户提供的内容（哪怕只是"餐厅应用"），提出少量澄清性问题来完善 PRD——目标受众、核心功能、平台（Web/移动端/两者都要）、必备项 vs 锦上添花、变现方式等。适合场景下使用
ask_user_input_v0进行快速多选澄清。 - 用户也可以跳过问答环节，直接自行写入 PRD.md——如果他们说"我自己来填"，创建一个带章节标题和占位符的 PRD.md 骨架，等待他们填写。
- 不要臆造功能。如果用户回答模糊，再次追问或提供选项——不要用假设来填补空白。
- 一旦 PRD 内容充实，写入 PRD.md，展示给用户，获得确认后再进入下一个文件。
第 2 阶段 — 其余文件逐个生成（Design.md 除外）
按此顺序：TechSpec.md → AppFlow.md → Schema.md → ImplementationPlan.md → Rules.md → Tracker.md → Design.md（最后处理，见第 2.5 阶段）。
对每个文件：
- 基于 PRD 和已有文件提出草稿，或者如果有真正需要决策的地方就问用户问题（如"这里应该用 PostgreSQL 还是更简单的 SQLite/Firebase？"）。
- 展示草稿，请求确认或修改。
- 只有用户对当前文件满意后，才进入下一个文件。
如果说"剩下的你自己填，不要瞎猜，认真想清楚再填"——意思是：做出合理且有理有据的选择，与 PRD 及已陈述的约束保持一致（不是随机/偷懒的默认值），但在开始构建前仍需将所有内容展示给用户审核。"不要瞎猜"在这里的意思是"不得违背或超出 PRD 的意图"——而不是"每个细节都问一遍"。
第 2.5 阶段 — Design.md（始终需要交互）
未经用户确认绝不能编写 Design.md：
- 整体风格方向（如极简 / 现代 / 活泼 / 企业 / 复古 / 粗野主义 / 玻璃态 / 暗色优先）——必要时提供
ask_user_input_v0选项。 - 配色方案——要么要求具体颜色/十六进制色值，要么提供 2-3 套与其选定风格匹配的方案供选择。
- 排版偏好、间距密度、任何他们喜欢的参考网站或应用。
只有在收集到这些输入后，才能编写 Design.md。
第 3 阶段 — 最终审查
- 全部 8 个文件草稿完成后，展示整个计划的简要摘要，请用户审阅所有内容（尤其是 Rules.md——询问是否要添加约束条件，如"不允许使用外部库""仅限 TypeScript""必须离线运行"等）。
- 明确询问："在我开始构建之前还有什么要修改的吗？"
第 4 阶段 — 构建
- 用户确认后，按照 ImplementationPlan.md 分步开始实施。
- 每完成一个步骤/任务，就在 Tracker.md 中标记完成（勾选项，如有必要可附简短备注/日期）。
- 未经用户明确指示，不得偏离 ImplementationPlan.md、Rules.md、TechSpec.md 或 Schema.md。
- 如果用户在构建中途给出了文件中没有的新指令：立即执行（用户指令是最终的），之后更新相关文件以保持文档同步。简要告知用户更新了哪些文件以及原因。
快速参考：决策规则
- 模糊的功能请求 → 先问，不要假设。
- 用户明确说"你来定""你自己想" → 做出合理的、符合 PRD 的选择，记录下来并提交审核——不要静默塞进去。
- 用户当前消息与文件产生冲突 → 以用户为准；然后同步该文件。
- Design.md → 必须先询问风格和配色，无例外。
- 任何已完成的任务 → 立即更新 Tracker.md。
- 项目中途转向 → 主动更新所有受影响文件，总结变更内容。
局限性
- 仅适用于全新项目。在已有代码库上运行会失败。
- 高度依赖初始 PRD 生成阶段用户输入的准确性。