-1. 后续所有内容的 AI 总结

一句话概括：本文从技术原理和人文反思两个维度拆解了”如何用好 AI”，并以开发项目为完整案例，给出一套可复用的七步协作工作流。

文章结构全文分两部分：第 0 节是核心论述，覆盖原理认知、哲学反思和方法论；第 1-7 节是实战案例，以开发项目为例演示方法论如何逐步落地。两者是主从关系——理解第 0 节的思考框架后，1-7 的每一步都是其自然推导。

第 0 节：核心论述 技术原理：AI 系统分为 LLM 和 Agent 两层。LLM 是语言层面的下一词预测引擎；Agent 是以 LLM 为底座，通过提示词、记忆、调度、工具四大能力构建的作业系统。两者边界正在模糊，架构仍未形成统一范式。

核心观点：使用 AI 是在让渡选择权来获取更强的执行能力。 这种让渡利大于弊，但需要警惕三件事——幻觉（语言分布 ≠ 物理真理，且倾向说人类想听的话）、训练者偏见（数据、奖励函数、偏好对齐均由人类设定，模型输出携带组织级倾向）、自省弱化（快速获得结果降低了人主动追问”为什么”的动机，主体性被稀释）。

六条方法经验（对冲风险的操作框架）：

步骤拆分——把任务拆成阶段，不试图一次完成
验证出处——要求 AI 给依据，并实际阅读它
识别思考方向——发现 AI 的推理路径，思考它为什么这么想
暴露意图——告诉 AI “为什么做”，不仅仅是”做什么”
注入方法论——把个人思维框架作为约束传递
设定边界——控制迭代深度，节省时间、token 和思考精力

关于审美：知道”什么是好的”依赖长期经验积累，AI 无法替代。能从具体维度评价结果好坏，才算具备审美——这决定了你能否判断 AI 的输出是否真正符合初衷。

第 1-7 节：七步工作流

信息调研——围绕角色、行业、代价、市场、交付五个维度，把模糊想法具体化，暴露意图和隐性约束
需求与约束——从正（必须做）反（禁止做）两面划定边界，压缩 AI 的自主决策空间
计划生成——用最强模型生成 PRD、plan、架构等文档；重点人工审阅 plan.md，识别隐含假设和幻觉需求
项目初始化——Git 版本管理 + AGENT.md 开发规则，确保任何时刻可回溯、可迁移
提示词工程——以「意图+功能+验收」描述需求，按原子粒度拆分对话，领域偏好固化到规则文件并定期迭代
优化调试——bug 时主动剪枝补充约束，不满意时给正反样例并说明理由，拒绝空洞的”再改改”
固化与复盘——经验回写模板，分析计划与执行偏差，把工具封装为 MCP/Skill，知识跟人走不锁在特定 APP

为什么值得读如果你已经在用 AI 但总觉得”结果差点意思”，这篇文章提供是一套从认知到操作的完整框架——先理解 AI 的能力边界和风险本质，再用结构化的方法把控每一步协作质量。第 0 节帮你建立判断力，第 1-7 节给你一条可以直接套用的路径。

0. 在使用 AI 之前

AI 作为工具，没有必要苛求所有人都用好它，但你越明白它的原理，就越能用好它。

从技术原理上，我们可以把 AI 分为 LLM 和 Agent，LLM 是基于 Transformer 构建出来的模型，模型需要经过pretraining、SFT、RLHF/DPO这一目前的标准流程构建，在云原生情景下，Agent 通过 API 调用运行在高性能服务器上的 LLM 来实现与人类的任务。

不过现在 LLM 已经有了 CoT、Reflection 等机制，不排除未来会演变成内生 Agent 模式，也不排除后续厂商会训练专用模型从而把模型从云端拉到本地作为助手工具。

而 Agent 更像是基于 LLM 形成的作业系统与感知系统，以提示词（Prompt）为入口，基于 Embedding 的记忆（Context/Profile/RAG）、调度（DAG/ReAct）、工具（MCP tool/Skill）为核心能力帮助人把需求实现。

不必被名词唬住，有太多东西是中间层，例如因为工具的提示词过长而并不每次都需要，于是就有了 Skill 这种渐进式披露，有些文档是按需查询且存储在第三方于是就形成了 RAG，而决定什么是记忆、什么是工具的边界也非常模糊，例如一个读取知识库的工具可以以 MCP 协议嵌入到 Agent 中，相信后续 Agent 的架构仍有较大的调整，毕竟还没形成业界统一的范式。

就像 DAG 里可以把 ReAct 认为是一个节点，Agent 之间也可以嵌套，形成 SubAgent，如此种种，但万变不离其宗，Agent 的是为完成人类指令的作业系统，而这一方面做的最好的当然就是操作系统，最终会与底层能力 LLM 达成平衡，也会与上下文大小、Token 成本和逻辑准确性达成平衡。

除了原理，AI 在人类学上成为了人实质的思考力的外延，在互动中成为了心理学意义上的人的「伙伴」和焦虑的来源，在政治经济上又成为新的基础设施，所以也会有一些 AI 哲学的讨论，我们确实正处于 AI 革命的历史中。

我个人认为，使用 AI 是在让渡选择权来获取更强的执行能力。

不同于以往大家对搜索结果信任程度不一，现在人类对 AI 的结果是远高于大多数渠道的，这种信任让我们在用 AI 学习、获取信息、决策的时候无形中放弃了其他渠道，它带来的好处就是比其他渠道都要快、多，也比大多数渠道准确。

我不反对这样，但要警惕，这是因为：

1）幻觉
2）AI 背后是训练者的倾向性
3）弱化了人的自省能力。

幻觉顾名思义，LLM 预测的下一个词建立在语言学的分布性假设上而不是真实的物理世界和数学逻辑上，其反映的是共识而非真理；它更倾向说人类想听的（RLHF 强化了这一过程），而不是一定正确的，所谓忠言逆耳对 AI 来说并不是第一位的。

AI 的预训练和 RLHF 带有明显的人类先验设定，数据集是人类给的，奖励函数是人类写的，DPO 也是人类选的，因此其生成的结果必然带有强烈的训练者属性，只是当下训练链条太长了，人数和数据规模较大抹平了个体的差异，但作为一个组织仍然有机会指导一个现网模型的确定性偏好。

最后则是 AI 能快速生成结果，弱化了人反思自省的能力，当所有问题都可以通过「代词+目的」表述的时候，人类会懒得思考那么多，比如为何这样、是否合乎逻辑、数据是否准确、影响有多大、如果按这样实施会如何，如果人不去思考这些，那最终他也无法判断 AI 给出的结果是否真的符合其初衷，从而稀释主体性，进而选择生物成本更低的方式，选择奶头乐。这种影响在有互联网和 AI 的时间内体现也许没有那么明显，毕竟使用工具本身就是人类的智慧（虽然有一定的负面效果，但这就是进化），但在无法使用 AI 的场景下，甚至需要即时决策呢？

不过总归来说利大于弊，弊端也只是分化了人群，只要注意注意我觉得还好，在让渡选择权的时候，在此过程中我遵循自己的方法经验，后文 1~7 可以见微知著：

了解并明确自己想要完成的目的预期要拆成哪些 AI 步骤，例如想要完成一个项目，那它分为：调研、需求约束、描述计划、修正计划、Demo 验证、分治实施、验收上线，那就要根据这个步骤指导自己与 AI 对话，不要试图一下子完成全部内容
识别 AI 的先验假设，要求 AI 提供决策的依据和出处，并实际地阅读它
识别 AI 自主构建的思考方向，且要思考为什么 AI 是这么想的
向 AI 补充你的意图，而不是仅告诉它完成什么，以让他更好地服务你
把你的方法论，例如金字塔思维、MECE 告诉 AI 让他遵守
设定好完成的边界，不要无限迭代下去，做性价比高的事情，节省自己的时间、token，更重要的是节省思考的精力

至于老生常谈的所谓审美，仍然需要积累和练习，知道什么是好是依靠经验的，需要长期训练才能形成，比如一张好看的画外行只会觉得「卧槽牛逼」但是懂的人就可以通过构图、色彩、线条、视觉引导等各方面评价，知其所以美即审美。同样的，什么是好的想法，好的架构，好的逻辑，好的 AI 回复？

接下来我们以实现一个开发项目为例看看如何与 AI 协作，至于其他领域也可以作类似流程的拆分。

1. 信息调研确认意图

我的原始的想法只有一句话甚至一个单词，所以实现需求的第一步，应该是先跟 AI 讨论清楚如下问题：

角色：这个想法因何而来，要提供给谁使用
行业：有人做过吗，有现成的参考吗，怎么做的
代价：我打算花多大成本来实现它
市场：带给用户的价值是什么
结果：如何让 AI 衡量它做完了，交付的形式和指标是什么

在与 AI 调研的过程中，重要的是把自己原本抽象的想法具体到可判别的层面，由虚到实，让 AI 补充自己原本无法简单调研的信息。

这样做的好处是把意图暴露出来，人类比 AI 强的是在对话、想法前就能主动感知到背景、氛围等方面的信息，并建立各线索之间的联系。

因此，把这些隐秘的约束暴露给 AI，能让后续的工作减少相当多的分歧。

这一步实际上就是在跟 AI 讨论自己的想法到底要不要做，通过让 AI 收集信息来让朦胧的想法确定下来（或者不用做了）。

2. 关键需求和关键约束

在收集完信息后，可以让 AI 整理上述信息，然后来确认是否满足自己的初衷。

在这一阶段，提出的要求分正、反两方面，这是在明确需求的边界，我比较喜欢的表述是列出 N 条重点，以让 AI 来构建下一步计划。

这些重点项就包括了基于上述理解，形成的相对具体的内容，例如我在写量化信号系统的时候，因为我只希望每个标的最多 1 天调整 1 次，所以就形成了「使用每日交易统计指标作为数据，忽略日内分时数据」；

我有喜欢的框架，那就明确提出要求「使用 Django 作为后端，前端优先使用 React 和长期维护的 UI 库，且所有库应使用 CDN 加载，涉及的所有组件源应优先使用腾讯软件源」；

我需要保证开发环境干净，那就「必须使用 docker compose 运行开发环境」。

有些内容是禁止的，比如「禁止使用 alert 提示框，禁止引入需要付费的 API 和组件」

当然这里主要关注的是需求方面，具体开发过程的约束可以通过后续 AGENT.md 来实现，因此不用多提。

通过这些条条框框进一步对需求约束后，我们可以形成一段需求文档，和一长串对需求的约束。

3. 计划

把上述两部分信息提交给 AI，用你能用的最好的模型（当前是 Claude Opus 4.6)，告诉它：需要根据需求和约束条件生成：

prd.md: 产品需求文档，即功能、业务逻辑、界面等基本信息
plan.md: 需求计划说明，应按照需求关系，优先实现 MVP 版本，并把细化需求拆分多个开发阶段
architecture.md: 架构说明，使用文字和 mermaid 描述项目架构，描述项目的组件、模块、依赖关系
frontend.md: 前端需求与计划说明
backend.md: 后端需求与计划说明
appflow.md：描述预期中用户如何使用该 APP，需要对其产品意图、数据流向、用户交互设定等内容

注意，这里并没有生成 progress.md 这种进度文件，因为现在仍然在做需求拆分的工作，开发中的文档由下一步操作。

当然，根据需求大家也可以添加其他文档，这些都会参与形成项目的持久记忆。

比如，有的项目对 UI、UX 有详细要求，甚至找到了参考图，那就可以在 1、2 步的时候，让 AI 根据参考图，生成一个 ui.md 作为参考；

更进一步，可以要求 AI 生成一个 default.rule.md，作为初始的项目规则，明确表明哪些做、哪些不做、哪些要参考。

不过我个人认为在需求确认阶段去指导开发过程有些越俎代庖，应该解耦。

当拿到 AI 给的 md 文件后，最重要的事情就是去阅读并修改它，我比较建议你直接修改对应文件并用特定的标识符，例如我比较喜欢用 --> 来进一步解释我调整的原因。

特别是 plan.md，针对复杂需求，AI 生成的 plan.md 一定不是完美的，因为多数事情只有我们看到的时候才会意识到分歧，所以一定要认真读认真改 plan.md，并告诉 AI 为何改，然后让它调整到满意为止。

还要额外关注 AI 是不是引入了特定的假设，你需要找出它并且告诉 AI 这些假设不合理；还需要找到 AI 因为幻觉而生成的需求外需求，要尽量减少需求的分支，或者说减少 AI 自主决策，尽量让它做具体的事情。

最后，记得检查 AI 在开发过程中是否需要额外的信息，比如某些只有在特定公司才会用到的流程、mcp、skill 等等。

4. 初始化

在拿到上述一堆.md 后，先初始化本地 git 仓库——至少你需要一个版本管理工具，新建一个文档目录例如我喜欢的 .agent-doc，把这几个.md 放进去。

其次，你还需要准备一个对开发环境的约束文件并放到根目录下，我把它称之为 AGENT.TEMPLATE.md，我会放到附录里，它指导了 Agent 如何开发，包含:

开发规则：例如前后端开发规范，常用的工具，禁止的事项等
项目文档说明：一般指向.agent-doc，需要 AI 阅读并分析它
开发状态维护：何时修改，何时提交，如何提交，以确保任何时刻我们都可回溯
文档维护：记录开发调试过程，即每个 commit 背后的故事，特别是需要把在对话中积累的经验和习惯整理出来
如何测试等多种信息：说明开发环境如何运行和测试，特别是个人习惯例如 playwright

打开 IDE 的 Agent 比如 Cursor，或者 claude code 之类的 cli：

根据 @AGENT.TEMPLATE.md 初始化/实例化项目的 AGENT.md, 完成后删除 AGENT.TEMPLATE.md 即可
根据 .agent-doc中的内容，阅读并理解项目需求与架构，完善 AGENT.md，初始化开发文件，如 progress.md, bug.md, feat.md, chat-summary.md 等
完成后，按照要求，进行首次 commit 另外，如果你的项目有非常明确的架构，比如公司内通用的 SaaS 模版，我个人习惯是把参考项目放到 example 目录中，然后追加一条：
开发模版与架构参考 ./example/xxx ，仅参考架构，禁止复制不相关的功能

初始化后，你应该能得到一个较为友好的开发环境，后续不论你如何变更，总能溯源回现场，这很重要。

当然，每个人有不同的习惯，我只是个人喜欢用 AGENT.md 放这些东西，实际上所有个性化的开发规范都可以放在这里，甚至引入一些 mcp、skill 也是可以的，其实 AGENT.md 也是一种渐进式披露，因为更详细的规则在 AGENT.md 和.agent-doc 中。

需要强调的是.agent-doc/chat-summary.md，没有人是一开始就把脚手架设计好的，所以 AGENT.md 中会要求 commit 前检查是否有需要记忆的开发习惯或规则，记录到 chat-summary.md 中，当项目完结后，我们会根据 chat-summary.md，git commit log，来完善 AGENT.TEMPLATE.md。

5. 提示词工程

这些内容有太多人提了，从实现角度，用于实现特定功能的提示词应该参考 instruction following 设计的格式，即「角色定义+技能描述+思考方向+人格特点+用户指令」，以保障后续预测更为聚焦，不过在开始一个 chat 后，就没必要这么细节了，直接说需求就好。

建议采用：意图+功能+验收方式来描述自己的需求，让 AI 充分理解你为什么要做，要做哪些，以及如何衡量。

要注意主动拆分 chat，不要在一个 chat 中引入太多的上下文，应该一个原子需求在一个 chat 里完成和提交，以减少 Context Window。至于如何拆分出来原子的 chat，实际上就是 PM（项目经理）的工作，建议每个人都学一些，并把自己常用的方法论揉到提示词中区。

在提示词方面我认为重要的 2 个其他人比较少提及的部分有两个。

第一，是形成自己的 system prompt 特别是领域 prompt，不要试图每次都在 chat 中指定，善用 APP 自带的 rule/settings/instruction 来固化这些内容；

第二，是要定期优化自己的 prompt，这个优化分两部分，一个是让 AI 根据你的意图查漏补缺，让它来拟合对于 APP 的规则以达到最大跟随效果，另一方面是让 AI 根据你的长期记忆，总结和补充缺失的部分，重新归纳你的长期偏好和习惯。

没有什么提示词是一劳永逸的，迭代才是正道。

6. 优化

触发优化的条件无非是 bug 或者不够满意。

AI 的结果肯定不会一次满意，得益于之前的版本管理，有.agent-doc 和 commit message，至少可以随意回滚和切换 APP，在 Claude Code 不满意可以换 Codex，还不满意换 Cursor。也可以让不同的 APP 交叉检验自己的代码，特别是涉及到重大决策的系统。

在多数无法一次性修复的 bug 情形中，往往是 Agent 的思考方向出了问题，一般是我们给出的描述太过于宽泛了，Agent 要一个方向一个方向地尝试，如果要更快达成修复，人类就需要介入提供约束条件。

特别是你已经提问一轮了还没解决，不能像老板一样单纯指出来哪里哪里不行，要跳出当前循环，告诉 AI 你从哪里得到的日志、表现，告诉它预期结果，补充你认为这是 bug 的背景信息，还要认真阅读之前 AI 修 bug 的逻辑是否存在某种假设。

这里有多种方式来改进，例如要求 AI 变更前先说明理由，由你确认；也可以直接人类介入告诉它哪里可能有问题，哪里基本上不会有问题，主动剪枝（即主动排除不可能的原因）。

对于不够满意的部分，就需要直接指导 AI 朝着想要的方向努力了。

除了角色扮演来让 AI 激活知识库和训练数据，最常用的办法就是直接给参考对象。参考 preference pair 的思路，给出正反样例，并说明正例正在哪里、反例反在哪里，从而让 Agent 进行修复。这里最忌讳就是空洞说的「不满意，再改改」，基本上就是抽奖。

为了能清楚描述出来哪里满意以及提供改进方向，还需要人能顺利表达想法，这就是审美了，可以经常把两个有差异的内容让 AI 描述具体差异在哪里，并不推荐只给参考而不说理由。

7. 后续

把重复的东西固化，然后进行版本迭代。所以 AGENT.TEMPLATE.md 肯定是要在每个项目完成后进行版本更新的，一定要把停留在 APP 的用户画像迁移到你自己的本地模版和规则文件中去，不然换个 APP 还要重蹈覆辙。

我个人是不喜欢在特定 APP 上写全局、项目规则的，这种迁移一下 APP 就没了的东西必须要自动化。

再回忆一下为了实现这个需求在 AI 之外做了什么，比如查询某个内部的 DB、查看线上部署后的日志，那就应该直接把它们做成 MCP、Skill，让 AI 自己感知到。

我自己不喜欢胡乱添加 skill，因为 skill 隐藏了太多其开发者意图，往往与我预期不一致，只有遇到问题的时候，我会找喜欢的 skill 把它放到 iCloud 上，然后所有 APP 都 ln -s 它，使用的时候也明确指定并提出需求。

更进一步，还可以让 AI 分析一遍 commit log，结合 chat history 和 plan.md，看看最开始规划的方向和实际执行过程差距在哪里，通过这种简单复盘来提示我们后续应该怎么更好地编写 plan.md 和拆分子任务。

最后补充一些我认为非常重要的开发规则：

要求 AI 把不确定的信息通过提问收集
实现比完美重要得多，先实现 mvp demo 版本，再进行优化
所有变更从干净的现场开始，到干净的现场结束，即前后两次 git status 应该都是干净的，有 commit message 和 .agent-doc 描述本次变更的所有信息，commit message 和 .agent-doc 形成渐进式披露
重要变更要强制指导 Agent 反思：是否影响其他功能，是否有同类问题需要修改
多视角开发：自己和 AI 都要偶尔跳出开发者的角色，扮演用户/读者体验一下当前产品，是否满足：信息可见、可理解、设计一致、操作简洁、美观这一系列要求
人类要识别 AI 不具备的私有知识（特别是公司内部经验）、修正与预期不符的假设、调整 AI 低效的尝试方向
尽量补充需求意图，而不是直接指挥 AI 具体功能
多用 plan 模式，认真阅读每个构建的 plan.md 并完善它
形成符合自己习惯的项目目录和基本结构，特别是对于非开发项目，比如 .psd 、.ppt、.md 的版本历史都非常有意义，额外关注参考图参考文件的存储，不要轻易覆盖写入，最好能放在需求文档的二级目录下
了解原理才能超过普通的 AI 使用者

AI 使用经验以及如何开发一个项目

目录