感谢佬友的激情分享， ^-^ 拿下来学习一下。

搞了篇 Blog 记录一下。

从「让 AI 写代码」到「让 AI 理解你」——我的 AI 编程成长路径

最早用 AI 写代码的时候，我和大多数人一样：扔一段需求过去，拿到一段代码，能用就用，不能用就再问一次。那时候觉得 AI 是个更聪明的搜索引擎，能省点打字时间。

但用着用着，我发现了一件事：AI 的输出质量，几乎完全取决于你给它什么上下文。 同样的需求，换一种描述方式、多给两行背景信息、或者把验收标准写清楚，结果就能从"勉强能用"变成"直接可用"。

道理不复杂——AI 在基于你给的上下文做 next token prediction。上下文越精准，预测范围越小，输出相关性越高。这个认知后来成了我所有 AI 编程实践的基石。

知道了"上下文决定质量"之后，我自然开始想：如果一轮不够好，能不能多来几轮？

于是我摸索出一个工作模式：给上下文和验收标准，AI 生成答案，把答案作为新上下文再输入，循环直到满足标准。听起来朴素，但效果实打实——单次对话正确率大概 20%，通过迭代能推到 70%-80%。每一轮都在帮 AI 缩小预测空间，第一轮理解 60% 的意图，第二轮反馈对比后修正到 80%，再来一轮基本到位。

这让我意识到：AI 编程的核心不是 prompt engineering 的技巧，而是工作流的设计。 你不需要一个"完美的 prompt"，你需要一个能持续给 AI 正确反馈的循环。

但迭代循环也带来了新问题。

最明显的是上下文腐化。对话越长、无关信息越多，AI 的输出质量越差。聊了 50 轮的对话，AI 可能连第 3 轮定的规则都忘了，开始自己编东西。还有指令遵循问题——你定了一套规范，前几轮严格遵守，后面就开始走样。不是它不想遵守，而是上下文膨胀后，那些指令在注意力里被稀释了。

这两个问题让我认识到：LLM 有固有的结构性缺陷，靠更好的 prompt 解决不了，必须靠工程手段来规避。

我的应对是主动、频繁地清空或隔离上下文——后来发现 Subagent 天然适合做这件事；用 Slash Command 精准触发，替代长对话中的口头指令；把复杂规范固化为独立文档，不每次重复说一遍。

另一个相关的坑是上下文膨胀。任务太长、细节太多，理解不到位就直接扔给 AI，它做得缺斤少两——不是不想做全，是任务太大，有限上下文里装不下那么多关注点。

后来换了思路：让 AI 自己把大任务拆成小步骤。拆到什么粒度？我摸索出一个经验值——单个子 agent 完成一个任务，整个循环大概消耗 10 万 token。太多就漏信息、顾此失彼；太少就反复做重复的事。这个数字是实践中反复调整后找到的甜区。

这也让我对"任务拆分"有了新认识：以前觉得是为了让工作更清晰，现在意识到本质是控制单个 agent 的上下文窗口大小，让它每次执行都保持足够的注意力密度。

解决了上下文问题之后，我开始想一个更大的事：能不能把这套方法论变成可复用的工程体系，而不是每次都靠个人经验？

这就有了后来我做的 T-Tools。

T-Tools 的核心思路是把 AI 编程从"临时问答"升级成"可执行的工程工作流"。每个工作阶段做成独立的 Skill 命令，Agent 按工程角色拆开（后端开发、前端测试、E2E 演示、只读验收），共享规则抽象成 Protocol，整个开发串成一条带质量门禁的链路：PRD → Design → Task → Run → Demo 验收。

这里面有几个我觉得比较关键的设计选择。一是每个阶段都有 check，不跳过——跳过就是把上游问题带到下游，越往后修正成本越高。二是 Demo 验收独立于其他测试，用 Playwright 跑真实浏览器模拟用户完整路径，验证的是"用户能不能真的用这个功能"。三是串行执行，任意时刻最多一个任务 running——牺牲速度，换来更强的可控性。AI 编程最大的风险不是慢，而是失控。

在落地这套工程体系的过程中，我还遇到了一个以前不太在意的问题：工程化基础设施的速度。

以前手写代码，测试跑个二三十分钟完全可以接受。写几十行，跑一次测试，看结果，改改再来。编译速度、测试并发、增量构建的优先级很低——你等得起。

但 AI 编程彻底改变这个方程。AI 在迭代循环里可能反复生成、编译、运行十几次甚至几十次。如果每次编译 5 分钟、测试套件 20 分钟，一个 Dev-Test-Accept 循环就耗掉一两个小时——而这只是其中一个 item，一个功能可能有十几个 item。

这意味着以前可以容忍的工程化短板，在 AI 编程下变成了致命瓶颈。 并发测试执行、增量编译、测试选择和隔离、构建缓存——手工编程时代"有了更好、没有也行"的能力，在 AI 编程时代变成"没有就跑不动"的硬性要求。AI 编程倒逼工程化能力强制升级。以前工程化服务于人的效率，现在服务于 AI 的迭代速度。两者对速度的容忍度差了好几个数量级。

工程链路跑通之后，我以为自己找到了终极答案。但真正做了几个项目之后，一个让我不舒服的事实浮现了：东西能跑起来，但最终的 UI 交互体验很差。

问题出在哪？我回过头来想，发现根子其实在 PRD。

PRD 本质上是文字描述。命名怎么取、流程怎么走、交互怎么衔接——用文字写出来后，连自己都不想多看几遍，更别说指望 AI 严格执行了。脑子里一个模糊的画面，翻译成文字，AI 再把文字翻译成代码，两层转译之后，最终产品和预期差距大得离谱。而且你还不清哪里不对——文字本身就不够精确，没法定位偏差。

改起来更痛苦。改一个交互细节往往牵连后端逻辑，一套修改三四个小时，Token 消耗千万级别。验证流程和测试环节一个也省不了，绝大部分 Token 花在了"纠偏"而不是"创造"上。

这让我开始怀疑一个基本假设：PRD 作为 AI 编程的起点，到底对不对？

我试着换个角度：不先从 PRD 切入，而是从 UI 和交互切入。先明确要做什么，直接定义界面长什么样、用户怎么操作。AI 生成页面后，通过视觉快速判断哪里缺东西、哪里不对劲，再让 AI 基于页面反向理解和补全 PRD。

最近有个流行做法是让 AI 直接输出 HTML 而不是 Markdown，本质上和我的思路一致——借助视觉形态快速确认 AI 的理解是否正确。人眼看一个页面，一秒钟就能判断布局对不对、交互顺不顺、功能缺不缺。逐行审查文字描述或代码的效率低得可怜。从 UI 倒着推还有一个关键好处：看到页面不对时，反馈是即时的、具体的——“按钮应该在右边”“列表应该有筛选”“流程少了一步”。这些反馈不需要经过文字转译，AI 接收到的信号更精准。

这套思路我还没有完全落地，但流程想清楚了：先不写完整 PRD，而是做一份 MVP 级别的视觉描述——若干带标注注释的 HTML 页面，甚至包含简单的 JS 交互示意。把这份材料交给 AI，告诉它需要调整的地方和关注的核心点，同时保存交互历史。然后基于这些视觉材料和对话记录，反向生成 PRD。我把它称为"AI 时代的 PRD"——以可视化为核心。别人一看就能大致想象出产品的功能和样子。更进一步，可以让 AI 针对用户故事生成交互视频——你口述操作流程，AI 输出演示，再结合文档重新整理。这样产出的 PRD 既有视觉又有动态演示，能大幅减少理解偏差。最后借助 T-Tools 的工程化能力，把"可视化 PRD"转译成最终产品。

回到原点，所有这些尝试——迭代循环、工程化体系、视觉优先的工作流——其实都在回答同一个问题：你如何确认 AI 真的理解了你的意图？

文字 PRD 的问题是，人和 AI 之间隔了一层文字转译。你说"登录后跳转到首页"，AI 理解的"首页"和你脑子里的可能完全不一样。用文字审查文字，偏差几乎不可见。HTML 页面和交互演示之所以有效，是因为它们把"理解验证"从文字维度拉到了视觉维度——看一眼就知道对不对，效率比文字审查高几个数量级。

所以 AI 编程的核心挑战：不只是让 AI 写出能跑的代码，更是让 AI 在写代码之前就和你对齐了意图。工程化解决"写出来能不能跑"，视觉优先解决"跑的东西是不是你要的"。

回头看这段路径，有一个认知是从头到尾没变过的：人的角色不是"写代码的人"，而是"流程设计者、契约制定者和最终验收官"。

AI 可以写代码、写测试、写文档，但人需要设计工作流、制定规范、把控质量门禁。人在 AI 编程中的核心价值，从"动手"转向了"设计和判断"。工程化的核心取舍也是这个——用更多结构换更少自由发挥。模型仍然负责推理和实现，但必须沿着文档、状态、契约和门禁前进。

写到这里，其实还有一个问题一直在脑子里转，没想透，但觉得很重要：如何让 AI 的输出更专业化？

前面说的所有方法——精准上下文、迭代循环、工程化工作流、视觉优先验证——都在解决"如何让 AI 做对"。但"做对"和"做好"是两回事。AI 可以按 PRD 把功能实现出来，但交互设计够不够专业？信息架构合不合理？代码是不是真的遵循了最佳实践？这些不是靠更好的 prompt 或更严格的门禁就能解决的。

我真正在思考的是：专业知识应该怎么喂给 AI？

一种直觉是把领域专家的经验和判断标准整理成文档、指南、检查清单，灌进 AI 的工作流里——把 UX 设计原则写成 guide，把后端架构的 trade-off 写成 protocol，把测试策略写成 checklist。前面说的 guide 和 protocol 其实已经在这个方向上走了一步。

但另一种可能性更让我在意：也许真正需要提升的不是 AI 知识库的容量，而是人自己的心智模型。

如果你对领域没有足够的认知维度和评估标准，你甚至不知道 AI 的输出"差在哪"——能看出"不对"，但说不出"为什么不对"和"应该怎样才对"。给 AI 的反馈是模糊的、低效的，迭代再多轮也收敛不到专业水准。反过来，如果你有清晰的心智模型——知道好的交互设计应满足什么标准，知道合理的架构应避免什么陷阱，能把"感觉不对"拆解成具体可操作的反馈——那 AI 的输出质量会有质的提升。不是因为你写了更好的 prompt，而是因为你的每一次反馈都更精准、更有方向性。

这引出一个值得讨论的问题：未来的 AI 协作，是"把流程全部推给 AI"，还是"人先建立心智模型，再反哺 AI 工作流"？

前者的逻辑是 AI 越来越强，专业知识会被模型内化，人只需要最终验收。后者的逻辑是人的认知深度决定了 AI 输出的上限，人不提升，AI 再强也只是在错误方向上加速。我倾向于后者，但还不确定。也许答案是某种中间态：人需要有足够的心智模型来提出正确的问题、给出有效的反馈，但不需要亲自掌握每一个执行细节。就像建筑设计师不需要亲自砌墙，但必须理解结构力学和空间逻辑，否则连图纸都画不对。

这个问题我没有答案，写在这里，供讨论。

从最初发现"上下文决定质量"，到摸索迭代循环，到遭遇上下文腐化瓶颈，到沉淀出一套工程化体系，到质疑"PRD 优先"的起点，再到对"专业化知识该放在哪里"的困惑——这个过程本身也是一个 Dev-Test-Accept 循环。

每解决一层问题，就暴露出下一层。工程化解决了"AI 能不能按规范交付"，视觉优先试图解决"交付的东西是不是你要的"，专业化的问题追问的是"你要的那个标准本身够不够高"。

AI 编程还在快速演进。但有一点越来越确定：核心挑战始终是"意图对齐"——如何确认 AI 真的理解了你要什么。 而意图对齐的前提，是你自己清楚"我要什么"。工程化是手段，视觉验证是手段，心智模型才是地基。Prompt 是战术，工作流是战略，对齐验证是战略中的战略，而人的认知深度，决定了这一切的天花板。

在上一篇 blog 里中，我梳理了从" 从「让 AI 写代码」到「让 AI 理解你」“的完整路径——从发现上下文决定质量，到迭代循环，再到工程化体系 T-Tools，最终落脚于可视化优先的工作流。那篇文章的核心是"意图对齐”：如何确认 AI 真正理解了你想要什么。

但它留下了一个未展开的前提：假设系统已经稳定运行，工程流程已然顺畅。信息“熵增”的魔鬼悄然而至。

项目信息，总在悄然过期

随着业务持续迭代，项目信息不可避免地沦为"过去式"：一段注释对应着三个月前的逻辑，一份文档描述的是已废弃的流程，某条配置指向早已下线的服务。这些过期信息并非只是无用——它们明确地提供错误信号，会误导 AI 的判断。

更棘手的是，这些过期信息几乎无法系统性地清理。目前尚无可靠的方案能自动识别、清除和更正它们。我当前的做法是反复让 AI 执行各类审查——代码审查、文档审查、逻辑一致性检查——以减缓错误信息的增长。效果确实有一些，但代价是大量消耗 token，而且只能减缓，无法根治。

好比一个房间，若不加整理，自然趋于混乱。AI 编程加速了信息的产出，却未带来与之匹配的整理能力。

代码结构：渐进的偏离

除信息问题外，代码结构的走样同样棘手。

项目初期，你会建立清晰的架构——目录组织、模块划分、职责分配。但随着迭代，特例需求不断涌现。某个需求与现有结构不甚匹配，AI 按照自身理解给出一个"还算可行"的方案。接着又一个特例，又一次妥协。几轮下来，原本清晰的结构便逐渐走样。

这不是代码质量的滑坡，而是一致性的流失。犹如一条规划好的公路，走着走着岔路和便道越来越多，虽然每条都有当时的理由，但整体已不再是完整的公路。

我采取的应对是定期做代码扫描，甚至编写专用脚本，每隔几次提交就运行检查结构的偏离程度。这些手段有用，但本质上是事后的修补，而非机制上的预防。

好消息是，对于后端业务逻辑，这个问题相对可控。只要测试覆盖足够、场景验证到位，后端的正确性基本有保障。逻辑正确时，结构偏差不至导致功能错误。

但前端……

前端：最难驾驭的环节

前端是我目前认为最棘手的领域。每一次 AI 的产出，几乎都会埋下隐藏颇深的"脏点"。

所谓"脏"并非代码写得糟糕——实际上 AI 生成的代码单看质量不差——而是同一功能，会不断引入各异其趣的实现方式。同样一个列表筛选，三次需求可能用上三种状态管理方式；同一个表单提交，两次实现可能沿着完全不同的数据流路径。

核心矛盾在于一致性缺失。不是代码差，而是同样的东西，写法越来越散漫。

我目前在做一些尝试：

样式方面，通过 DESIGN.md 约束规整度。将设计规范固化为文档，在每次任务启动前注入给 AI，让它处于同一套规范体系内。效果是有的，至少避免了同一个按钮在三个页面长得各不相同。

代码逻辑方面，我尚未找到好的解法。尤其状态管理——有时使用全局状态，有时则采用组件内部状态，其间的边界连人都不易厘清，更遑论交给 AI 判断。

后端有测试兜底，前端缺乏这种安全网。你很难用测试去验证"这段代码的状态管理方式是否与项目其余部分一致"。这并非增加几个测试能解决的问题。

人的介入：何时与如何

谈到这里，便避不开一个更根本的问题：在整个 AI 编程流程中，人应该在何时介入，介入到什么程度？

从验收的角度，人必然是最终把关者，这一点没有争议。但验收不应只在最后一刻——如果人仅待代码写完才投以一瞥，彼时可改之处已所剩无几。

更上游的疑问是：在需求提出、AI 给出 PRD 和前端 UI 的阶段，人是否应提前做一轮验收？

我目前观察到三个问题：

第一，人对项目的掌控在不知不觉中流失。 PRD 本身蕴含巨量信息。当越来越多工作移交给 AI，人对项目的全局感知便逐渐稀释。你或许清晰记得三个月前的决策逻辑，但对上周 AI 所做的小调整可能毫无印象。

第二，AI 给出的方案天然"孤立"。 每次方案自身逻辑自洽，却往往未充分考量项目当前状态。置于全局，可能与既有的设计理念冲突、与其他模块的接口不匹配、与整体架构方向相左。而人进行审计时，因信息量过大，实际上也很难识别这些深层冲突。

第三，审计能做到的事情本身有限。 当前审计能提升的，主要集中于逻辑和技术方案层面——有经验的架构师确实能通过更精准的提示词引导 AI 给出更合理的方案。但涉及交互体验与功能持续叠加，现有 AI 协作模式几近无力。

这里还有一个更深的空白：目前没有统一方案，能借助多模态大模型，基于 UI/UX 规范对产品进行完整评估。开源社区中，我也未见有谁在此方向取得实质性突破。一个能理解设计规范、评估交互体验并给出具体反馈的自动化产品评估工具——或许将是未来两年 AI 协作编程中值得关注的发力点。

不过，理论归理论，实际操作中我也摸索出了一套自己的介入节奏。

PRD 完成时，我一定会让 AI 先出一份简单的 HTML 页面，并附上具体的实现说明。这样做的好处是直观——你能快速了解它的实现意图，也能较早识别其能力边界。紧接着，我会让它针对 PRD 提出疑问，由我逐一回答，确保双方对需求的理解一致。

之后，人工介入的重心就落在了验收上。验收我拆成两个阶段。

一是前端 Demo 完成后立即验收。此时后续的 Demo 尚未启动，问题在早期即被拦截，后续迭代可以直接规避同类错误。核心收益在于降低 Token 消耗——错误没有被机会在后续流程中累积放大。

二是等所有 Demo 跑完、已知问题全部修复后再验收。好处是你不必分心处理低级 Bug，精力可以集中在更本质的偏差上。但即便 PRD 阶段讨论得再充分，从后端代码到前端代码的转化过程中，依然会出现相当大的偏差——UI 样式的走样、逻辑细节的偏移，往往到这一步才会浮现。

两种策略各有所长，也各有代价。越晚介入，低级 Bug 越少，但修正偏差所需的 Token 量也越多。

RAG：难以胜任

在寻找解决方案时，不可避免会考虑 RAG（检索增强生成）。但实际使用后，我的感受是：RAG 作为编程辅助，尚欠火候。

根本原因在于，RAG 的检索逻辑与编程的信息结构并不匹配。RAG 本质上接近关键词搜索——你描述需求，它返回相关片段。而编程中的信息并非扁平的文本片段，它具有高度的结构性：方法之间的调用关系、类的依赖、接口的实现、逻辑对流程的影响。这些信息需通过"跳转"来收集——正如在 IDE 中，按住 Ctrl 从一个方法进入其实现，再跳至它调用的核心方法，层层追溯。

我认为，这种模式最终可能更适合由边缘端小模型承担。一个本地运行的小模型，能直接访问项目代码的结构信息，沿调用链收集上下文，给出精准的辅助。但现实是，目前边缘端模型能力与硬件算力均尚不足。

或许要到 2027 年以后——随着小模型能力提升，加上端侧硬件（特别是 NPU）的进一步发展——才可能成为现实。届时，本地小模型处理代码结构化追溯，云端大模型处理复杂推理与代码生成，两者配合，精准且高效，计算开销也将远小于当下把所有任务抛给大模型。

写在最后

这些问题有一个共同的底色：信息熵增，无法被彻底破解。

想想那些超大型代码库——无论当初架构设计多么精良，最终都难免沦为"屎山"。并非某人写烂，而是无数业务迭代逐渐堆积而成。能怎么办？只能依靠持续的测试与重构，勉强维持其"尚可使用"的状态。秩序天然会走向混乱，你只能投入精力去维系，永无一劳永逸。

AI 编程亦是如此。它加速了代码的生产，也加速了混乱的积累。信息过期、结构走样、一致性散失——这些并非 AI 带来的新问题，而是软件工程自古即有的顽疾，只不过 AI 让它们发生得更快、更隐蔽。

所以我想说的是：AI 编程不是银弹。 它能让一个人承担五人的工作量，却无法阻止项目的持续腐化。它解决的是效率问题，而非熵增问题。效率可借助工具提升，而熵增只能靠人反复不断地维护。

写这篇文章，并非为了泼冷水。我自己每天都在用 AI 写代码，而且确实已经离不开。只是觉得，与其期待某天这些问题自动消失，不如坦然承认它们的存在，并在承认的基点上，厘清哪些值得花力气去管，哪些只能接受。

认清边界，比盲目乐观更有用。

T-Tools 下一步除了继续精细 skill 指令，大方向是奔着多 Agent 协作去走了，但现在关于多 Agent 协作的底层架构还不成熟，没有统一规范，先记录下多 Agent 协作思路，看看后续怎么搞。

头脑风暴这种发散任务， 目标不是标准答案，越散越好。几个 Agent 的上下文互相“污染”，刚好能带进去一点随机偏差，有个胡说八道了也没事，总结时容易被更好的点子盖掉。

可对于编程，就不行了。写代码第一要精准——规范得守，风格得一致，行为得可预期， 还要多跑验证，多Agent 很容易就打架， 目前思路是只有一个 Agent 负责写入，一个Agent负责调度，其余负责各个维度思考。但这个思路的存在两个问题：

1. 调度 Agent上下文容易爆炸，指令遵循要求极高。


2. 协作并行度不够。

可以按照 git worktree 的方法来缓解，将调度 Agent 代码化执行，去管理多分支干活，每个分支会有一个调度Agent来调度该分支里的代码编写。分支过完CI后，再触发 “合并 Agent ”进行合并。

但目前 claude code 或 codex 的hook 功能不够，大概率是要基于 Pi 框架做调度 Agent 代码化开发才行， 或者挂 MCP，通过 MCP 做上下文隔离，但上限会低。

PS: claude code 最近出的 /workflow，通过代码的方式动态编排，能比较好的实现上述调度，估计再过几个版本，就会是标配了。

用 T-Tools 做了个轻量 RAG 客服 rwiki，耗时不到四天， token 使用量约 5亿， 过程十分丝滑。

/t-html-show skill 这种将 AI 生成的 markdown 转化为 HTML 的方法，可极大提升人类理解效率。

/t-dream 像人类一样做梦， 通过各维度对齐， 清理老旧、不准确的prd，重新组织文档结构。

就是有点耗 Token，中型AI Vibe Coding 项目 rmqtt-things，轻轻松松 2千万Token 开销。

/t-prd 产生的 prd文档，为了方便后续AI阅读执行，它必须是一个单独文件，且要描述好要变更的内容等。但会导致 prd 目录组织结构散碎以及各种无用历史内容。

为了解决此问题， /t-prd 演变成编写 prd 草稿，当prd全实现后，再由 /t-prd-publish 基于 prd草稿对现有 prd 进行整理。

我列个天，大佬就是不一样啊 就是字都是别人的几倍

好文章，为什么我这么晚才看见^-^ 佬对prd文档撰写模板有研究吗？什么样的prd是ai理解最好的？

web-dev-skills/skills/t-prd/template.md at main · timzaak/web-dev-skills · GitHub 这是 t-tools 的模版，有点糙。 ai 时代的 prd 应该分两部分，一部分是让 ai 能快速阅读，md格式，好指导后面的 ai 去校准代码方向，另一部份是你人能快速审计，可以让 ai 生成图片 或者 html。

佬写的真不错，现在的AI Coding Agent本质上还是一个编程工具，架构的设计和减速腐化速度才是人能把控的方向。期待佬友的更多好文