过去一段时间，我利用 Cursor/Trae 等 AI 编程工具，从零开发了一款名为 ThinkingMap 的可视化思考 Agent 。这里总结了我的一些实战经验，希望对大家有帮助
一、 幻觉与现实：AI 编程的真实体感
在官方演示里，AI 似乎能一键生成应用。但在真实复杂的业务场景中，体验往往是割裂的：
- 爽点：写 DTO 、校验逻辑、正则、单元测试、样板代码飞快；类型推断极其精准。
- 痛点：写一些中看不中用的玩具很炫酷，但是要想按自己想法则需要一些方法去引导约束；一旦代码量大了，经常出现"逻辑幻觉"。
核心认知：现阶段的 AI 编程工具是“加速器”，而不是“自动驾驶”。当你清楚要去哪（架构清晰、需求明确），它能带你飙车；当你自己都没想清楚，它会把你带沟里或者做出来的东西不是你想要的。
二、 核心心法：文档驱动开发 (Context Engineering)
这是我最大的收获：不要直接对着 Chat 窗口敲需求，要用文档说话。
在复杂项目中，单纯靠对话维持上下文是不可能的。我采用"文档驱动"的方式，把所有约束显式化：
-
**建立
docs/目录作为"外挂大脑"**：prd.md：讲清楚产品要干嘛，不做嘛。architecture.md：前后端技术选型、目录结构、数据流向。frontend-rules.md：显式规定"用 Shadcn UI"、"状态管理用 Zustand"、"必须写 TS 类型"。database.md：表结构设计。
-
把文档作为 Prompt 的上下文：
- 每次开新功能，先让 AI 读取相关文档。
- 比如："@docs/prd.md @docs/frontend-rules.md 请根据 PRD 中的'节点展开'功能，按前端规范生成 Zustand Store 代码。"
效果：这极大地降低了 AI "胡乱发挥"的概率，保证了代码风格的一致性。
三、 从想法到产品三部曲：聊功能、写文档、敲代码
经过反复摩擦，我发现直接让 AI 写代码往往效果不佳。真正高效的路径，是将 AI 深度融入到从想法到落地的全流程中：
1. 聊功能：丰富与细化需求
在写第一行代码前，先把它当做产品经理或技术顾问。
- 场景：当你只有一个模糊的想法（如"我想做一个思维导图"）。
- 动作：让 AI 帮你拆解场景、用户价值和核心功能点。
-
Prompt 示例：
"我想做一个可视化思考工具，核心痛点是 AI 对话不可控。请帮我拆解用户的使用流程，并列出 MVP 版本必须包含的功能模块。"
- 产出：通过多轮对话，将模糊的直觉收敛为清晰的功能列表和交互逻辑。
2. 产出文档：后续开发的基石
这是最关键的一步。 聊完后，必须把共识沉淀为文档，而不是留在聊天记录里。
- 动作：要求 AI 将讨论结果整理成 Markdown 文档（ PRD 、UI 线框描述、技术方案）。
- 价值：这些文档是后续开发的"宪法"。在后续 Coding 阶段，通过
@docs/xxx.md引用这些文档，能极大降低 AI 的幻觉，保证上下文不丢失。 - 经验：不要指望 AI 能记住 10 轮之前的对话，但它永远能读懂你喂给它的文档。
3. 写代码实现：基于文档的执行
有了前两步的铺垫，写代码就变成了"开卷考试"。
- 动作：引用文档，明确约束，进行分块生成。
-
Prompt 模板：
"基于 @docs/prd.md 中的'节点展开'功能，并参考 @docs/design.md 的数据结构，请实现对应的后端接口。 注意：遵循 @docs/backend-rules.md 中的错误处理规范。"
- 结果：因为有了文档作为"锚点"，AI 生成的代码不仅逻辑正确，而且能完美契合项目架构，无需反复在此阶段纠正业务逻辑。
- 审查：最后依然要根据审查清单，对生成的代码进行严格把关。一定要保持对代码的掌控力，否则越到后面越发感觉无从下手
关联项目👇
GitHub 项目：thinking-map
项目里记录了开发过程中较详细的文档，并整理了一些博客，感兴趣的朋友们可以看看，互相交流一下 AI 编程和 Agent 开发的经验
以上均为个人观点，不喜勿喷🫥
Select Language