AI写代码不是万能钥匙，真正的关键在你自己
- 在 AI 时代，代码规范和质量依然同样重要。AI 再聪明，也无法弥补一个混乱的项目结构。
- 如果项目本身就是屎山，那 AI 写出来的自然也不会变黄金。垃圾输入，只会有垃圾输出。
- AI 是“遇强则强，遇弱则弱”。你越懂技术、越懂需求，AI 的输出就越惊艳。
- 不要幻想 AI 一键帮你搞定所有事。它是工具，不是魔法。
- 真正的心法：把自己当指挥官，AI 当你的打手。
需求开发文档模版定义
对于在现有项目中新需求开发，我通常会使用下面这个 需求开发文档模版
markdown
## Feature
## Documentation
## Tips
- 修改过的文件中添加注释 `TODO: ${需求名称}-开发中` 字样
- development 和 logs 文件夹下文件除外
- 功能实现如依赖第三方插件，请使用 PNPM 包管理工具
- 无需过多考虑功能的完整性
- 如果需要额外添加需求未提到的功能，请先询问我获取我的同意，在进行扩展
- 无需修复导入顺序和类型导入的问题
- 在修复其问题如果出现长期无法修复的问题，需要在文件中标志注释 `TODO: 类型问题-待修复` 即可
- 然后跳过类型修复问题
- 需求功能开发后后都需要在当前标题标注【已完成】
- 最后需求完成后，总结一份日志报告
- 要整体描述需求/BUG，以及需求功能的实现或BUG修复内容，以及修改的文件路径和描述具体改了什么
- 输出报告至 `logs` 文件夹中，文件名为：`${YYYYMMDD}-${需求名称}.md`- 提示词：
@INITIAL.md查看文档需求，完成功能开发
新功能模版设计定义
markdown
## Feature
## Tips
- 按照提出的功能需求完成设计，无需过多扩展
- 输出一份功能模块设计的报告至 `features` 文件夹中，文件名为：`${YYYYMMDD}-${需求名称}.md`- 提示词：
@DESIGN.md查看文档需求，完成功能模块设计
集成文档模块定义
markdown
## Feature
## Documentation
## Tips
- 写一篇集成文档，输出报告至 `docs` 文件夹中，文件名为：`${YYYYMMDD}-${需求名称}.md`- 提示词：
@DOC.md查看文档需求，完成集成文档
各家模型理解对比
- 推理能力强的模型
GPT、Claude
**适合：**复杂逻辑分析、代码问题排查、架构设计、需求拆分 **特点：**思考链条更稳定，能处理多步推理 **短板：**速度较慢、偶尔过度自信
- 代码能力强的模型
GPT、Claude、DeepSeek、GLM
**适合：**重构、生成项目模板、适合明确的需求开发 **特点：**能保持同一项目的风格一致 **短板：**对业务理解有限，需要提供明确上下文
- 语言表达能力强的模型
GPT、Grok
适合： 适合写文档 特点： 表达自然，结构清晰 短板： 事实信息需要校验
实际场景中对于需要让 AI 去定位问题或者设计新模会使用推理能力强的模型 Codex（GPT）去制定整体规范完成第一轮。然后交给 DeppSeek 或者 GLM 完成明确的需求开发。然后平时知识性问答之类的，不参与到具体项目的。我都是使用 GPT 或者 Grok 询问。