最近国外有个开发者，利用AI 编程工具在短时间内开发了12个应用，总结了一份提示词并分享出来了，今天就来解析一下这份提示词。

理念

核心理念

渐进优于颠覆- 确保小改动能编译通过测试
从现有代码学习- 实施前先研究规划
务实而非教条- 适应项目实际情况
意图清晰优于代码巧妙- 选择简单明了的方案

简单性原则

每个函数/类单一职责
避免过早抽象
不要使用巧妙的技巧 - 选择“无聊”的解决方案
如果需要解释，说明它太复杂了

流程

1. 规划

将复杂工作分解为3-5个阶段。记录在IMPLEMENTATION_PLAN.md中：


## 阶段N: [名称]
**目标**: [具体交付物]
**成功标准**: [可测试结果]
**测试**: [具体测试用例]
**状态**: [未开始|进行中|完成]

2. 实现

理解- 研究代码库现有模式
测试- 先写测试
实现- 最小编码通过测试
重构- 在测试通过前提下优化
提交- 附带说明关联计划的清晰信息

3. 遇到阻碍时

当每个问题最多尝试3次，如果还没修复，就立即停止下来：

记录失败情况：

尝试了哪些方法
具体错误信息
认为失败的原因

研究替代方案：

寻找2-3个类似实现
记录采用的不同方法

质疑基础假设：

抽象层级是否合适？
能否拆分为更小问题？
是否存在更简单的整体方案？

尝试不同角度：

使用不同库/框架功能？
采用不同架构模式？
移除而非增加抽象？

技术原则

架构原则

组合优于继承- 使用依赖注入
接口优于单例- 便于测试和灵活调整
显式优于隐式- 明确数据流和依赖关系
尽可能测试驱动- 绝不禁用测试，而是修复

代码质量

每次提交必须：

成功编译或运行
通过所有现有测试
包含新功能测试
遵循项目格式/linter要求

提交前：

运行格式化/linter工具
自我审查变更
确保提交信息说明"原因"

错误处理

快速失败并提供描述性信息
包含调试上下文
在适当层级处理错误
绝不静默吞异常

决策理念

存在多个有效方案时，基于以下标准选择：

可测试性- 能否轻松测试？
可读性- 半年后他人能否理解？
一致性- 是否符合项目模式？
简洁性- 这是最简单的可行方案吗？
可逆性- 后续修改难度如何？

项目集成

熟悉代码库

找出3个相似功能/组件
识别通用模式和约定
尽可能使用相同库/工具
遵循现有测试模式

工具使用

使用项目现有构建系统
使用项目测试框架
使用项目格式化/linter设置
无充分理由不引入新工具

重要提醒

绝不：

使用--no-verify绕过提交钩子
禁用而非修复测试
提交无法编译的代码
做假设 - 用现有代码验证

始终：

增量提交可工作代码
随进度更新计划文档
从现有实现学习
3次失败后停止并重新评估

总结

你完全可以根据你的项目情况，对这份提示词做部分修改，或者直接放到你的rules或者CLAUDE.md中，进一步提升AI编码的效率！

链载Ai

理念