最近有个国外的开发者在圈子里分享了一份提示词，说是用Claude Code在很短时间里搞定了12个应用，还把这套工作流总结得相当系统。今天就来拆解一下这份提示词，看看人家是怎么做到的。
整份提示词的核心，其实就一句话：别让AI替你乱写，而是让它按照一套成熟的工程规范来干活。下面从理念、流程、技术原则、决策逻辑到项目集成，一点一点说清楚。
理念
核心理念
这套工作流基于四条核心理念，也是所有操作的底层逻辑：
- 渐进优于碘伏 – 别看不上小改动，确保每次小步提交都能编译通过并跑通原有测试，这才是稳定迭代的前提。
- 从现有代码学习 – 动手之前先研究现有代码里的模式，别自己闭门造车。
- 务实而非教条 – 项目有项目的实际情况，别把书上的理论当死命令。
- 意图清晰优于代码巧妙 – 解决方案越简单明了，后面接手的人就越省心。
简单性原则
原则的具体落实，其实也就几条硬规矩：每个函数或类只干一件事；别急着做抽象，写多了再回头看要不要提炼；不要搞花里胡哨的技巧，选择“无聊”但靠谱的方案；如果你的代码需要长篇解释才能让人看懂，那说明它已经太复杂了。
流程
1. 规划
把复杂工作拆解成3到5个阶段，每个阶段写进 IMPLEMENTATION_PLAN.md 里，模板长这样：
## 阶段N: [名称]
**目标**: [具体交付物]
**成功标准**: [可测试结果]
**测试**: [具体测试用例]
**状态**: [未开始|进行中|完成]
2. 实现
每个阶段的实现走五个步骤：先理解代码库现有模式，再写测试，接着写最少的代码让测试通过，然后在测试通过的前提下进行重构，最后带上清晰的提交信息提交。顺序不能乱，质量是倒逼出来的。
3. 遇到阻碍时
这是整份提示词里最实用的一条：每个问题最多尝试3次，如果还没修好，立刻停下来。不是放弃，是换个思路。停下来之后要做四件事：
- 记录失败情况 – 尝试了哪些方法、具体的错误信息、自己认为的失败原因，都记下来。
- 研究替代方案 – 在代码库里找2到3个类似实现，看看别人用了什么不同的方法。
- 质疑基础假设 – 抽象层级对吗？能不能拆成更小的问题？有没有更简单的整体方案？
- 尝试不同角度 – 换一个库或框架的功能来试？换一种架构模式？或者，不是加抽象，而是干脆拆掉一些抽象？
技术原则
架构原则
- 组合优于继承 – 多用依赖注入，少玩类继承。
- 接口优于单例 – 接口保证可测试性和灵活性。
- 显式优于隐式 – 数据流和依赖关系必须明明白白。
- 尽可能测试驱动 – 遇到问题就修测试，而不是禁用它。
代码质量
- 每次提交必须：成功编译或运行、通过所有现有测试、包含新功能的测试、遵循项目的格式和linter规范。
- 提交前：先跑一遍格式化工具和linter，自己审查一遍变更内容，确保提交信息写清楚“为什么”改，而不是只写“改了什么”。
错误处理
- 快速失败，给出描述清晰的错误信息。
- 包含调试上下文，方便排查。
- 在合适的层级处理错误，别把异常往上抛一步就完事。
- 绝对不要静默地吞掉异常。
决策理念
当两个方案都可以，用这五个标准来选：可测试性（能不能轻松测试？）、可读性（半年后别人能不能看懂？）、一致性（是否符合项目现有模式？）、简洁性（这是最简单的可行方案吗？）、可逆性（如果后面要改，难度大不大？）。排在前面的优先级更高。
项目集成
熟悉代码库
- 先找出项目中3个类似的功能或组件。
- 识别通用的模式和约定。
- 尽可能复用项目里已有的库和工具。
- 测试的写法也要对齐现有模式。
工具使用
- 用项目现有的构建系统、测试框架、格式化工具和linter配置。没有足够充分的理由，不要引入新工具。
重要提醒
绝不：
- 用
--no-verify绕过提交钩子 - 禁用测试而不是修复它
- 提交不能编译的代码
- 做任何假设，一定要用现有代码去验证
始终：
- 增量提交可以工作的代码
- 随进度更新计划文档
- 从已有的实现中学习
- 3次尝试失败后停下来，重新评估再出发
总结
这套工作流看起来条条框框不少，但它真正解决的是人和AI合作中最容易失控的问题——让AI明白你的质量标准，也让每一步都有迹可循。完全可以根据自己的项目情况做一些调整，把它直接放进你的 rules 或者 CLAUDE.md 里，效果会比零散的口头提要求好得多。