ESSAY
别再堆超级 Prompt 了
“真正可靠的 AI 工作流，不是把所有能力揉成一个大脑，而是让不同能力在正确边界内协作。”
核心观点 / 起源
当 Claude Code 这类 AI 编程工具开始支持 Skills 之后，很多重复出现的协作方式就不再只是临时 prompt，而可以被封装成稳定的工作流入口。一个 skill 可以负责追问需求，一个 skill 可以负责结合文档统一术语，一个 skill 可以负责测试驱动开发，还有一个 skill 可以把讨论整理成需求文档。
这听起来很美好，但问题也随之出现：当工具箱里的 skill 越来越多时，真正困难的事情不再是“有没有能力”，而是“现在该用哪个能力”。
我把自己为这个问题做的入口命名为 project-compass。这个名字不是某个官方概念，而是我专门起的名字。compass 是指南针，project-compass 的意思就是“项目指南针”：它不负责替你完成所有事情，而是在一个项目请求出现时，先判断方向，再把请求路由到合适的下游 skill。
这里的“路由”很关键。project-compass 不是万能总控，也不是超级 prompt。它更像一个分诊台：如果你只是有一个模糊想法，它应该把你送到负责追问和澄清的流程；如果你已经有代码和文档，但概念混乱，它应该把你送到负责统一术语和沉淀决策的流程；如果你已经明确要实现一个功能或修一个 bug，它应该把你送到测试驱动的开发流程。
细节展开
后面会提到几个具体 skill。它们来自公开的 mattpocock/skills 体系，可以理解为一组面向 Claude Code 的可复用协作流程：grill-me 负责通过连续追问把模糊想法问清楚；grill-with-docs 会结合项目文档和领域语言一起校准设计；tdd 负责按红绿重构的方式推进实现或修复；to-prd 则把讨论整理成结构化的需求文档。还有 diagnose、verify、code-review、security-review 等，分别对应调试、验证、审查和安全检查。
所以，project-compass 要解决的不是“怎么把所有 skill 拼成一个更大的 skill”，而是另一个更小、更重要的问题：当前这个请求，到底处在哪个项目阶段？
一个人刚开始使用 AI 编程助手时，往往会把注意力放在模型能力上。模型够不够聪明？上下文够不够长？代码写得够不够快？这些当然重要，但当工具进入日常使用后，真正拉开差距的往往不是单次回答质量，而是流程质量。
比如，同样是“我想做一个功能”，它背后可能是完全不同的阶段。
如果想法还很模糊，直接写代码只会把不确定性固化成一堆文件。这个时候更适合先用 grill-me，把用户、场景、边界、优先级问清楚。
如果项目已经做了一段时间，但每个人对模块、概念、字段的叫法都不一致，那么问题就不是需求不清，而是语言系统失控。这时更适合用 grill-with-docs，让 AI 回到现有文档、CONTEXT、ADR 和代码语境里校准术语。
如果目标已经明确，下一步就是实现或修复，那就不应该继续空谈设计，而应该进入 tdd，用测试先约束行为，再让实现跟上。
如果讨论已经足够清楚，需要给团队、老师、自己未来的执行阶段留下结构化材料，to-prd 才是更合适的出口。
这些 skill 单独看都不复杂，问题在于它们放在一起后会产生新的选择成本。用户不一定每次都能准确判断：我现在是在澄清需求，还是在统一概念？是在验证想法，还是已经该写测试？是在整理文档，还是只是想要一份临时总结？
这就是路由器出现的理由。它不是为了增加一个新能力，而是为了降低选择成本。
过程 / 推演
很自然的冲动是：既然这些 skill 都有用，那能不能把它们揉成一个超级 skill？一个入口判断所有情况、生成所有文档、写所有测试、做所有审查，最好还能自动推进整个项目。
这个想法看起来省事，实际上危险。
因为不同阶段需要的不是同一种智能。澄清阶段需要的是慢下来、追问、拆掉含混表达；实现阶段需要的是收敛、写测试、让代码满足可观察行为；诊断阶段需要的是复现、缩小范围、提出假设和加仪表；审查阶段需要的是站在变更之外找风险。
如果把这些节奏揉进一个巨大 prompt，表面上入口变少了，实际上边界变糊了。边界一糊，AI 就容易在不该执行时执行，在该追问时开始写代码，在只需要分诊时长篇解释方法论。
路由器最怕的不是能力不够，而是太想表现自己。
一个 project-compass 如果开始解释所有开发方法、罗列所有 skill、替代下游流程、自动做复杂决策，它就不再是指南针，而变成了一张过度拥挤的地图。地图越大，用户越难判断现在应该看哪里。
好的路由器应该克制。它的价值不是把所有路都走一遍，而是在岔路口告诉你：现在走这条。
project-compass 更适合被设计成一个薄路由器。
所谓薄，不是功能弱，而是责任窄。它只做三件事：识别当前阶段，判断最合适的下游 skill，在路线明确时尽快交接。
它的判断模型可以压缩成一句话：不要从用户标签出发，要从当前任务出发。
当前请求如果是“我有个想法但不知道怎么展开”，路线就是 grill-me。当前请求如果是“这个项目里术语、模块、决策一直变”，路线就是 grill-with-docs。当前请求如果是“帮我实现这个明确功能，最好稳一点”，路线就是 tdd。当前请求如果是“先做个能玩的版本看看”，路线就是 prototype。当前请求如果是“这个 bug 很怪，不知道根因”，路线就是 diagnose。当前请求如果是“确认这个改动真的生效”，路线就是 verify。
这些规则不需要很花哨，恰恰应该足够直接。一个路由条件如果需要解释半天，说明它本身还没被设计清楚。
同样重要的是，不是什么 skill 都应该塞进 project-compass。像配置管理、快捷键设置、定时循环、学习测验这类能力，当然也有用，但它们不属于项目生命周期的主干分诊。把它们都放进来，只会让 project-compass 从工作流路由器膨胀成 skill 目录。
目录的目标是完整，路由器的目标是命中。
一点补充
设计路由器时，有一个非常容易犯的错误：把用户画像当成当前上下文。
比如，一个用户曾经说过自己是学生。这个信息有价值，但它只能帮助 AI 调整解释方式。它可以让 AI 多举课程项目、作业、个人练习的例子，也可以让 AI 在解释复杂概念时少一点公司黑话。
但它不能推出“这个用户当前做的一定是学生项目”。
同一个学生可以做课程项目，也可以做个人工具、开源贡献、实习工作、生产系统、研究实验。反过来，一个职业开发者也可能在做练手项目或学习项目。身份是身份，项目是项目，任务是任务。
如果路由器把“用户是学生”误当成“当前项目是学生项目”，它就可能进一步推出“不是学生项目，所以不适用”。这个判断链路看起来合理，其实从第一步就错了。
更稳定的规则应该是：用户身份影响表达方式，当前请求和可见项目上下文决定路由。
这条规则不只适用于 project-compass，也适用于所有带记忆的 AI 工作流。记忆可以让协作更贴近用户，但不能替代对当前任务的观察。否则记忆就会从“辅助理解”变成“先入为主”。
如果把 project-compass 的经验抽象出来，一个好的 AI 工作流路由器至少要满足四条标准。
第一，少量高频路径。路由器不需要覆盖所有可能性，它应该优先覆盖最常出现、最容易选错、最能改变结果质量的阶段。需求澄清、术语校准、测试实现、问题诊断、效果验证、质量审查，这些才是项目推进中的主干分岔。
第二，清晰触发条件。每条路线都应该能被一句话判断。模糊想法去澄清，概念混乱去文档校准，明确实现去 TDD，难复现问题去诊断，已有改动去验证或审查。触发条件越清楚，误触发越少。
第三，低误触发率。路由器宁可少接管，也不要乱接管。尤其不能用用户身份、过往偏好、单个关键词来替代当前上下文。一个好的路由器应该先问“这个请求现在要解决什么问题”，而不是先问“这个用户通常是什么类型”。
第四，快速交接。路由器的使命是减少选择成本，不是展示自己知道很多。路线明确时，一句话说明原因，然后交给下游 skill；路线不明确时，最多问几个短问题；两个路线都合理时，给出取舍，让用户选。
这四条标准背后其实是同一个原则：路由器应该知道自己什么时候停手。
结语 / 反思
AI 工作流的成熟，不是把一个 agent 训练成什么都做，而是让不同能力在正确边界内协作。
project-compass 这个名字里最重要的不是 project，而是 compass。指南针不会替你走路，也不会把整张地图塞到你面前。它只在你需要判断方向的时候，稳定地指出下一步该往哪里走。
这也是我对 AI 自动化越来越明确的一个判断：未来真正可靠的工作流，不会只依赖一个越来越大的 prompt，而会依赖一组边界清楚、能互相交接的能力。
所以，设计一个入口时，最值得问的不是“还能加什么功能”，而是“它应该在什么时候停手”。