夜雨聆风7天前，我打开电脑，看着一份自己整理了很久的资料，却懒得翻开它。 7天后，这份资料，变成了一个智能体系统。
这篇文章，是这7天的完整复盘。
Day1：从一份懒得翻的文档，到想清楚要做什么
某天打开电脑，看到一个Word文档——是我过去多次整理的资料，有目录，有标题，内容非常全面，但是也多，导致不想动手去翻。哪怕可以通过标题目录甚至关键字搜索，但是我就是懒得翻。
那一刻我意识到，问题不在资料不够，而在资料越堆越厚。一个职场人最终要沉淀的，不该是一份越来越厚的案例库，而是自己的方法论——理念、原则、流程，以及用工具的方法。一直往文档里堆案例、堆题目，本质上还停留在"信息收集"，没有真正提炼成方法论。
于是冒出一个念头：能不能把这套东西，做成一个智能体系统？
而且这个需求不只属于我。比如很多公司会有话术培训，可话术只是能力（方法论是能力的一部分）的一种表现形式，能力在，遇到新情况能随机应变；能力不在，背再多话术也只是照本宣科。在大模型出现之前，针对每个人做"千人千面"的考核，工作量大到不现实，只能退而求其次去考记忆。大模型刚好改变了这件事的成本结构。
所以我的判断是：哪怕这个系统最终没能商业化，对我自己来说，它也是一个训练自己、提升自己的工具，值得认真投入时间去做。
一个克制的决定
需求逐渐清晰，基于做过SaaS系统的经历，我也动过做成SaaS的念头：万一做好了，说不定能卖给有需求的中小公司呢？
但脑子里马上冒出一个画面——第一次做多智能体系统时的惨状。
那次以为AI编程无敌，把以前做产品的流程全扔了。结果和AI对话到火冒三丈，键盘感觉要被敲碎，骂了N次大模型智障蠢货。让它改一个bug，改了；过几天迭代别的功能，回头一看，整个系统一塌糊涂。
所以这次理智第一时间介入：不能扩太大，记住最小闭环。是我一个人在指挥AI干活，AI目前还得一步一步盯着指挥，需求一旦扩大，只有一个人加AI，风险也跟着放大，SaaS先不做。
Day2-3：可行性探讨、把需求文档细化
于是着手和各个大模型交流探讨这个需求的可行性，便开始写需求文档。曾经以为可以不用写需求文档的，可是之前用AI编程工具做的第一个多智能体系统的经历又浮现在眼前——当时觉得自己都写过那么多需求了，有了AI可以不用写了吧，我脑子肯定很清楚的，可以尝试一下。
可是事实是，这是我第一次经历了那种传说中的需求混乱。需求方（我）不知道自己要什么，同时又什么都想要，想要一个自动化的还可以实现各种复杂场景的，可是给AI就只有一句话的需求，最后导致的就是表结构混乱，在这种情况下AI更乱，表搞错，表字段搞错，最后以为开发完毕了，结果是原地踏步。
这种经历在告诫我自己，需求文档一定是要写的，可以写到80%的程度，但是不能不写。那20%是一些细节的逻辑自洽、闭环之类的内容，假如是自己使用的工具，确实可以尝试不写，AI会自己补全；但是对于大型系统来说，现阶段还是该写到100%。再也不想经历那种糟糕的事情，所以需求文档必须写。在有AI的前提下，其实需求文档可以换一种角度来写，需求调研之后，可以和大模型探讨需求分析，可以和大模型协作完成需求文档。
于是列出了核心用户、用户需求场景、用户使用流程，和大模型一起完成表结构的设计，制定规则、约束，数据流向，涉及的状态，异常处理机制等。
Day2聚焦某个模块。
Day3聚焦另一个模块。
这两天最大的感受是：有AI协助，写需求文档的速度确实快了很多。在写需求文档中，AI充当了效率杠杆以及思维助手，可以快速补全细节，而我需要做的是补充、判断、下指令修改等。
Day4-6：需求文档定稿，AI编码、测试
到第四天，需求文档差不多成型了。我把它发给了几个不同的大模型，让它们交叉审视，看有没有遗漏的场景，逻辑是否自洽。然后开始谋划动手开发：把需求文档丢给AI编程工具，让大模型给出技术选型建议。几家给出的方案差别不大，判断问题不大，准备开工。
但这次动工前，我比第一次谨慎太多。原因是，第一个多智能体系统留下的坑，这次一个都不想再踩。
第一次项目踩过的坑
第一次做多智能体系统，与其说是"开发"，不如说是"探索式踩坑"——当时的心态更像是玩，把需求文档的约束全部丢开，想到哪就指挥AI干到哪（其实根本没想清楚，只是自以为想清楚了）。结果把传说中的糟糕经历完整经历了一遍：
- 数据库配置方式要提前确认：平台对数据库是只支持默认配置，还是既支持默认又支持手动配置，如果平台主打默认配置，却一开始让AI接入平台外的自建数据库，随着对话轮次增加、上下文拉长，AI会出现"注意力漂移"而忘记前提，甚至写出两套连接逻辑。毕竟现阶段新推出的自然语言AI编程工具应该都在逐步完善中，而且给AI的指令不见得每一次都十分明确，AI在开发过程中连接数据库的方式有时候就真的极其容易懵圈。就会出现AI说完成了，你去测试，其实没有完成，因为AI是在一个数据库内完成的，而你在另一个数据库测试的。
- 表结构要先于功能开发：哪怕用AI编程，遵循开发规范去"指挥"AI，比只给通俗语言描述目标，bug率能降低很多。先让AI把相关表结构建好，表名、字段名都经过推敲，甚至要考虑到AI后续识别这些名字的难度——完成度比"告诉AI做某个需求然后就不管了"要高得多。
- 中途删表重建，底层表结构震荡，是大忌：表名、字段命名一旦在开发中途变得混乱，除非自己有100%手动修正代码的能力，否则不如直接新开项目重来。AI在这种情况下是真的会手忙脚乱，不断引入无法修复的恶性Bug。
- 业务逻辑失控，中途大改流程与循环状态机要谨慎：中途突然大改业务流程、状态流转或提交保存逻辑，特别是状态机中涉及循环调用的复杂场景。面对这种高频且大幅度的逻辑重构，AI倾向于"头痛医头"，通过不断创建新函数来拆东墙补西墙。最终导致没有一个函数能满足完整需求，AI自身也会陷入逻辑死循环（一直转圈），失去全局掌控力。
- 提示词/命名污染：状态命名千万别中英文混用，命名要统一语言。大语言模型本质上是基于概率预测下一个词的"概率模型"，极度依赖上下文的语义连贯性。一旦命名中英混杂，会严重干扰模型的概率预测，导致生成的代码逻辑极其容易崩溃和混乱。
这些坑，第一次几乎是故意放飞自我踩出来的——后来那个项目还是老老实实重新梳理需求文档，重开项目，让AI从0实现。第二个项目能这么快，正是因为第一次该踩的坑基本都踩过了。还有这个项目的需求是经过很长时间沉淀的，只是刚好在两三天内突然变得很清晰，能提炼出来。
这次的开发方法论
需求文档写好后，先完整发给AI编程工具，让它理解，但不执行。接着告知AI按平台规范方式连接数据库。然后，表结构一个一个地给，AI建完一个表，去数据库检查无误，再扔下一个。所有表建完，再按模块拆分，把流程、规则、异常处理机制一块一块交给AI，而不是一股脑全部丢过去。没有什么交叉的模块，可以考虑分开不同对话上下文来完成。
编程基本完成后，开始测试。
冒烟测试：每个页面/功能做完，先做最基础的功能验证，确认没有问题。集成测试：单个模块测完后，验证模块和模块之间的数据流转、状态衔接是否正常。
回归测试：每次修复一个bug或新增功能后，不能只测新改的地方，还要重新跑一遍相关联的旧功能，确认没有引入新问题——在AI编程场景下，这一步几乎是刚需，因为AI的修改很容易"拆东墙补西墙"。
全流程测试（端到端测试）：所有模块跑通后，从用户视角完整走一遍流程，确认整体闭环没问题。
测试发现bug后，要注意给AI的指令，假如确实是修复bug而不是新增功能，要告知AI去查询代码而不是告知AI实现某某功能，不然AI会又给你新增函数什么的，那就真的是添乱。总结下来就是每一次给AI指令，要遵循AI就是个概率模型，靠预测下一个词来生成词然后执行任务的，所以给到AI的指令要明确。
Day7：发版，以及最后一公里的坑
测试修完，准备发版。结果这天集中暴露了一类问题：本地跑得好好的，一放到云端构建就报错。
第一次，是某个接口在构建阶段就去初始化数据库，但它依赖的配置只有真正运行时才存在，构建阶段拿不到，于是直接崩。修法是告诉框架"这个接口别在构建时提前处理，运行时再说"。
刚修好，另一个页面又炸了，报错长得不一样，根子却一模一样——还是"在构建阶段去碰只有运行时才有的东西"。
这时我反应过来：这不是某个页面的bug，是一类页面的共性问题。一个个修又慢、又大概率漏。于是换了思路，让AI把项目里所有同类问题的页面一次性搜出来、统一处理。
这天最大的收获不是哪行代码，而是：发现一类问题的模式后，要从逐个救火切换到批量根治。
两个坑修完，系统正式部署上线。
我真正学到的几件事
第一，AI编程没有取消"想清楚"这件事，只是改变了想清楚的方式。需求文档依然要写，但不用一个人闷头写，可以和大模型一起探讨着写。AI是放大器，不是替代品——你想得越清楚，它帮你跑得越快；你自己都没想清楚，它只会帮你更快地把混乱放大。
第二，给AI的指令颗粒度，决定了bug率。表结构先行，一次只给一小块，每给一块就验证一块——这比"告诉AI一个大需求然后等结果"靠谱得多。AI是一个概率模型，靠预测下一个最可能的词来生成内容并执行任务，指令越明确、命名越规范，它跑偏的概率就越低。
第三，区分"修bug"和"新增功能"的指令方式，能省掉很多返工。告诉AI"去查代码定位问题"，而不是"实现某功能"——后者很容易被AI理解成新需求，结果是新增一堆函数，越改越乱。
第四，审查权在你手里，但审查能力不会自动跟上，需要刻意建立审查习惯。 先问AI现状、要自然语言摘要、定期肉眼核对、善用回退——这些笨办法比盲目信任AI说的"完成了"靠谱。
第五，遇到反复出现的同类问题，要从根因批量解决，而不是一个个救火。
第六，在AI编程过程中，注意切换大模型，有的大模型真的浪费一堆token也解决不了问题，不要让天才大模型去解决小问题，也不要让平平无奇的大模型来解决复杂问题。
7天，它从一份我懒得翻开的Word文档，变成了一个我想用就可以精准打开来用的工具。对我来说，已达到最低目标。AI编程工具解决的是执行和效率层面的问题，而结构性的判断、要做什么、边界在哪，依然得靠人。
