AI的工程化应用与 ”过脑“

新闻

作者：微信文章

---

作为一个热衷于探索新事物的小白萌新，我最近对AI编程产生了浓厚兴趣。作为Augment Code早期30美元/月的用户，我在个人实践中踩了不少坑，也积累了一些心得，想在这里和大家分享。

在使用AI编程的过程中：

初期，我会用AI来设计门户页面（纯前端），直观感受它的编程能力和呈现效果；

进阶，开始尝试开发一些简单工具，比如带有基础API功能的前后端demo页面、展示页等；

深入后端，甚至用它搭建纯后端的服务，比如FastAPI——在技术老师确认服务量不大的情况下，有些代码甚至直接就能投入使用；

二次开发，借助开源框架和现成的上下文代码库，进行定制化功能开发；

内容创作，后来还利用AI IDE的上下文工程辅助撰写文章、专利、论文等；

……

如今AI IDE已经成为我日常工作中不可或缺的一部分。

但在使用AI IDE进行开发的过程中，我也遇到了一些颇为头疼的问题：

“抽卡”问题：由于大语言模型（LLM）固有的随机性，相同的提示词（Prompt）每次生成的代码结果都可能不同，充满了不确定性。

调试（Debug）难题：这是“抽卡”问题的延续，常常陷入“编程5分钟，Debug两小时”的窘境。


难以精准定位Bug的根源。

按照AI的建议修改后，代码行为并非预期，甚至产生新问题。

AI有时会误修改其他无关文件，带来额外麻烦。

……

这些也正是目前“Vibe Coding”（感觉式编程）模式下的主要痛点。

我的核心理解是：既然现阶段最终的责任主体依然是人，那么关键就不是让AI取代我们，而是如何利用AI，在整个产研阶段，让关键信息更好地被我们“过脑”，从而提升决策和代码质量。

---

首要挑战：如何应对“抽卡”问题？

为了“限制”模型的随机性，提高输出结果的可控性和一致性，初期的核心思路是：帮助AI更精确地理解用户的需求意图。

同样是“做一个网页”，不同开发者的具体期望和实现方式可能天差地别。因此，我们需要通过“记忆”和“规则”来将抽象需求具象化。

记忆（Memory）：


短期记忆：如会话历史、检查点（Checkpoints），让AI知晓当前的上下文。

长期记忆：如整个代码库的索引（Index）、用户前期的编码风格与习惯等。


规则（Rules）：通过预设的规则来约束AI的行为模式。例如：


是否需要生成模拟数据（Mock Data）？

每写完一个函数，是否必须自动生成对应的单元测试脚本？

这方面，Cursor推出的Rules功能就是一个典范。它允许在个人全局层面和单个项目层面分别设置规则，极大地塑造和统一了AI的“行为习惯”。



Spec Coding

基于以上思路进一步拓展——我们能否直接生成一份极致详细的需求文档，为AI编程提供一份“傻瓜式”指导？

因此Spec coding应运而生——其逻辑部分类似roo code的 Architect: 在开发之前，先生成系统文档，用来”指导约束”以及“规范”后续的开发结果， 例如openai 的 codex、亚马逊的 kiro Spec 和 阿里Qoder 的 quest模式等；

在实际的AI编程环境中，很多IDE还会通过To-do List的形式，清晰展示当前开发所处的步骤，并明确对应到Spec中的具体条款。这种方式有效帮助AI（和开发者）聚焦于当前任务，避免思维发散，确保编程过程不偏离预设轨道。

关于Spec Coding的详情，可以参考： 【北极的树】的 ”从Vibe到Spec：让AI编程更可控的结构化思考“ https://zhuanlan.zhihu.com/p/1950860088207193974





roo code 的 5种内置模式以及 todo list







Qoder-Quest mode 的 spec-first 以及 to-do list

回归本质：为何需要“过脑”?

在进一步探讨之前，我们不妨回归一个最基础的问题：为什么软件开发需要如此繁琐的流程？

从互联网产品研发的标准流程来看，通常包含以下几个关键步骤：用户确认 → 需求分析 → 产品原型设计 → UI设计 → 前后端开发 → 测试 → 验收 → 上线

这其中牵涉的角色：（需求分析师、）产品经理、UI设计师、前端/后端工程师、测试工程师

这一整套流程的本质，是为了确保需求被准确传达，让团队中的每个人都同步理解、统一目标，也就是我们所说的“过脑”，从而避免工作方向跑偏。

这一点与LLM（大语言模型）每次输出结果可能不一致的情况非常相似：如果一个需求没有经过明确的约束就直接进入开发，即便是同一个人，在没有“记忆”的情况下，今天和后天产出的结果也可能大相径庭——更不用说在多人协作中，这种理解的偏差会被不断放大。

再往底层推导，在需求层面，这些“约束”就可以间接的理解为用户需求的具体实现。在产品上线前，需求是否被正确实现，正是通过测试用例和验收标准来衡量的。因此，Spec Coding 中通常都会包含测试用例的设计，这正是为了确认对开发需求的理解是否到位。

既然整个周期仍由“人”来主导和管理（至少目前如此），那么如何确定哪些是需要“过脑”的关键信息？我的理解是：

产品 & UI：我的需求是如何被转化为详细需求文档的？

开发：根据需求文档，我的技术方案是什么？包含哪些模块？每个模块如何实现？

测试：根据需求文档，我的测试方案是什么？又该如何执行？

---

产品&UI的”过脑“信息：我的需求是怎么转化成详细需求文档的

这个过程与Spec Coding的理念高度一致。

产品经理可以先通过deep research及agent对话相关方法，梳理用户及其需求。

接着基于需求，继续与AI对话，逐步梳理和细化文档中的业务逻辑与交互细节，确保需求的清晰与自洽。

但是我个人始终认为，文字还是过于抽象，不如直接上图来的直观，特别是产品与开发之间存在着对于实现效果上相当大的技术认知信息差。

因此，我建议在文字Spec之上，引入Google Stitch 这类AI原型工具——针对文档的一步步梳理直观效果的同时，直接将原型图甚至高保真UI稿生成出来，并最好能导出为HTML格式:





如此一来，我们得到的不仅是一份Spec文档，更是一份可交互的视觉参考。这能极大地强化对后续开发的约束与指引。当开发同学看到具象化的界面与代码时，能瞬间理解“哦，原来这个功能有可能是这样实现的”，从而在脑海中快速完成从技术方案到视觉呈现的映射。

这种基于原型驱动的编码方式，我倾向于称之为 Prototype-Based Coding(PBC)，或者更直白地叫它 Spec+ Coding。它通过可视化的方式，极大地压缩了信息误差，让“过脑”变得更高效、更精准。

也就是说，在产品文档阶段，作为需求的管理者，技术层面怎么画出来这个html图对于产品关系不大；但是每个需求的最直观的效果，产品需要“过脑”并且精确的传递到后续的角色中去。

---

开发：根据需求文档，我怎么实现？




对于开发角色，其核心的“过脑”问题是：“根据需求文档，我该如何实现？”

在拥有了原型和Spec之后，开发者的核心任务便转向技术架构的构建。此处的思路与产品梳理需求文档类似，目标是输出一份技术架构文档。但由于开发的核心目的在于确保程序内部参数的准确传递与处理，因此这份文档需要是文本与可视模块化的结合。

模块化：将系统拆分为清晰的逻辑模块、函数，并明确每个部分的入参、出参与职责。

解决核心问题-debug困难：一个配套的、可交互的可视化模块化环境至关重要。它应能实现：


当AI完成一个模块的编程后，实时显示其入参与出参的实际数据；

代码行与可视化模块保持同步高亮；

Debug时，自动高亮当前模块直接关联的上下游模块；

允许开发者（或AI）选中特定模块，将Debug上下文限制在当前范围，精准定位问题，避免AI盲目修改、引入错误。

在开发阶段，“过脑”体现在两个层面：

技术架构的可视化呈现：通过模块化文档，让系统结构和技术方案一目了然。

Debug过程中的高效交互：即使初始的Spec不够完美，Debug环境也能通过一步步调试，反向优化和修正最初的设计，形成一个持续改进的正向反馈循环。

---

测试：根据需求文档，我的测试方案是什么？如何实现？

对于测试角色，其核心的“过脑”问题是：“根据需求文档，我的测试方案是什么？又该如何实现？”

测试阶段的工作流与开发环节相似——其核心同样是基于明确的输入，生成结构化的输出。测试人员可以将前序产出的 PBC 文档（含Spec与原型） 输入到AI IDE中，让AI逐步“过脑”，据此生成清晰的测试文档，这包括具体的测试用例、性能压测方案等。

在此基础上，测试工作可以进一步自动化：

脚本生成：直接利用AI IDE编写可执行的测试脚本，例如用于端到端测试的 computer-use 或 browser-use 指令，或是用于接口验证与负载测试的API脚本。

智能执行：更进一步，可以直接调用AI浏览器等智能体，来执行这些交互操作脚本，自动完成点击、输入、验证等全流程测试，并将结果直观反馈。

通过这种方式，测试不再仅仅是最终的验证关卡，而是贯穿于“过脑”全过程的质量保证环节。它确保每一个在产品和开发阶段被明确下来的需求，最终都有一个可量化、可自动化的验收标准，从而真正闭合了整个协作环路。

---

总结：AI工程化的核心是“过脑”的闭环



核心目标——更精准的信息传递：每一个角色（产品经理、开发、测试）的文档形成，在文本描述的基础上，需要有可视化的辅助，确保大家可以在需求的理解上统一。

每个文档的形成部分，需要构建一个完整的“过脑”体系。 它不是一个单一的技巧，而是一套将模糊需求逐步转化为稳定、可靠产出的系统方法。在每个关键节点——产品、开发、测试——都将自己的思考过程“外化”为AI可精准理解的指令与约束。

---

参考：

【北极的树】的 ”从Vibe到Spec：让AI编程更可控的结构化思考： https://zhuanlan.zhihu.com/p/1950860088207193974