企业官网建设流程全解析

3个人，5个月，100万行代码。这个数字在圈子里流转的时候，大多数人的第一反应是“不可能”。但如果我告诉你，这三个人几乎不怎么敲键盘，大部分代码是AI生成的，你可能觉得更离谱。我跟踪过类似的AI工程实践，老实说，这个团队真正厉害的地方不在于“让AI写代码”，而在于他们建立了一整套约束AI产出的工程方法。这套方法被他们称为“缰绳工程”——人类负责驾马，AI负责狂奔，缰绳决定方向和边界。这篇东西就是想把“缰绳工程”这套逻辑掰开揉碎讲清楚：它解决什么问题、怎么落地、有哪些坑，以及你接不接受这种“不写代码”的协作方式。

1. 别被“100万行”唬住：先说清楚这套方案到底解决了什么问题

1.1 “不写代码”不是玄学，是职责重心的转移

很多人一看到“不写代码”就兴奋，以为AI已经能完全替代程序员了，程序员要失业了。这个理解基本是错的。那3个人5个月产出100万行代码，如果去掉AI辅助，按一个成熟开发者的正常速度，每人每年也就写两三万行有效代码，3个人5个月能写出来的有效代码量可能也就是一两万行，和100万行差了两个数量级。所以他们说的“不写代码”，准确意思是“人不亲自逐行敲代码，人的精力转移到更上游的设计和更下游的验收上”。

我见过不少团队在引入AI编程工具的时候踩同一个坑：要么让AI完全自由发挥，结果生成一大堆看似结构漂亮的代码，一合并发现架构混乱，没人能维护；要么把所有希望寄托在“让AI一次生成对”上，结果生成的代码质量不稳定，最后还是要人工返工。真正的问题不是AI写不出代码，而是AI写出的代码“不可控”。“缰绳工程”解决的就是这个不可控问题：用一整套约束机制、任务拆解方式、验证闭环和人在回路流程，把AI的生成能力关进笼子里。

这种思路本质上是把传统软件工程中的“契约先行、测试先行、小步迭代”原则，平移到“AI作为执行者”的场景里。以前是人对人提需求，现在是人对AI提需求；以前靠代码评审约束人，现在靠任务描述和验收标准约束AI。职责重心从“怎么写”转向了“写什么、写到什么样算合格”。

1.2 为什么要叫“缰绳工程”——约束才是产能放大器

“缰绳”这个词用的是马术的意象。马力气大、跑得快，但如果没有缰绳，它可能跑进沟里或者不听话，甚至把人甩下来。你需要的不是在它跑偏时拼命拉绳子，而是在它跑起来之前就让它清楚路径和终点。AI生成代码也是同理，你不能等着Bug出现再让AI改，而应该在任务下发的源头把边界立住。

这套工程的几条核心约束是：

• 架构决策必须由人来做，模块内部的实现细节才交给AI。
• 每个AI任务必须包含明确的验收标准和测试要求。
• AI不得擅自修改公共接口、数据库结构、核心配置文件。
• 所有生成代码必须先过自动化测试，再进入人工走查。
• 分支粒度要小，一次任务只解决一个明确问题。

我实际试过之后发现，约束越多，AI的产出反而越快。因为AI不需要在多个模糊方案间反复试探，人机来回沟通的次数大幅减少。很多初用AI编程的人痛苦在于：没有约束的AI和没有提纲的实习生一样，看起来忙了一天，产出全是废活。缰绳工程就是把“废活”比例从30%压到5%以下的那套管理方式。

在开源社区里，有一个很流行的类比是“AI是喷气发动机，人是跑道控制塔”。发动机推力再大，跑道的长度、方向、障碍物信息都必须由控制塔提前设定好。AI编写代码的能力已经很强了，它缺的从来不是力量，而是方向和限速。这套方法论的核心价值，就是给AI建立一条高效的“工程跑道”。

2. 拆解“缰绳工程”的核心机制

2.1 把大目标嚼碎：任务分解与依赖编排

我见过很多AI辅助编程的团队，一开始就扔给AI一个大任务：“帮我写个人力资源管理系统”，然后期待AI输出一个可运行的项目。结果往往是AI生成了一个结构眼花缭乱但根本跑不起来的半成品，或者更糟——生成完第一部分之后就忘记之前已经定义了哪些数据表，进入一种“每句话都合理、整体却前后矛盾”的状态。这背后的本质是任务太大，超过了模型的有效上下文范围和一致维护能力。

缰绳工程的第一步，就是人和AI之间建立“任务分解层”。这和传统项目管理里的WBS（工作分解结构）很相似，但标准和约束更严格。一个任务单元必须满足下面几个条件：

• 能在一次上下文窗口内完整承载，通常涉及的文件不超过10个。
• 有明确的输入依赖和输出产物，不依赖AI自己猜测。
• 有可执行的验收命令，比如npm test tests/user-service.spec.ts。
• 有明确禁止修改的文件列表。

举个例子。如果系统里需要一个“订单服务”，我不会让AI直接去实现订单服务，而是先把订单服务拆成：模型定义、数据库迁移脚本、服务层接口、日志与错误码、单元测试、对接支付模块的适配器。每个子任务都是一张独立的任务票，前后有依赖顺序。AI一次只处理一张票，完成并通过验证后才拿到下一张票。

在具体落地时，任务票通常用Markdown文件写出来，存进仓库的tasks/目录。内容包括：目标描述、涉及文件、依赖任务、验收命令、技术约束五块。有人觉得这很繁琐，但实操下来这种繁琐恰恰是省时间的。因为传统人写代码时，同一个开发者在脑子里可以自洽地管理大量上下文；AI不一样，它的“记忆”是上下文窗口，不写清楚它就忘。任务票就是AI的外置大脑。

2.2 给AI立规矩：编码规范、接口契约与上下文约束

AI生成的代码经常有一种“不断重构自己”的毛病：昨天生成的函数，今天它自己看不懂，然后生成一个重复实现。要解决这个问题，光靠任务拆解不够，还要立下三条规矩。

第一，编码规范必须显式化，不能依赖AI“看代码风格自行体会”。比如：项目使用TypeScript严格模式、禁止any、禁止console.log残留、函数必须小于30行、所有异步错误必须由调用方处理而非吞掉。这些规范写进项目根目录的AGENTS.md或CODEGUIDE.md文件里，AI每次读取上下文时都会看到。

我见过一个团队的做法很有意思：他们把编码规范写成了一条条“不得”句式，告诉AI不能做什么比能做什么更有效。“不得修改公共接口”“不得在服务层直接写SQL”“不得自行引入新的日期处理库”……这种禁令式规则极大减少了AI的自由发挥空间。

第二，接口契约先行。这算是我反复强调的一点：先定接口再写实现。AI在实现模块前，必须看到已定义好的接口文件。比如我定义好userRepository.findById(id): Promise<User | null>，AI就只需要实现这个方法的内部逻辑。接口是先行的“骨架”，AI往里填肉。如果没有这层约束，AI就会从接口开始自由发挥，导致模块与模块之间对不上。

第三，控制上下文漂移。长任务里AI经常“忘事儿”，这是上下文丢失导致的。我的应对方法是把关键信息压缩进一个context.md，每次新开对话（或新开Agent实例）时先加载这个文件。里面记录当前模块已经完成了什么、哪些决策不能推翻、下一步任务是什么。文件大小控制在50行以内，避免信息过载。

这三条规矩合在一起，效果就是：AI的创造力被限定在一个“安全区”内，它可以在这个区域里自由发挥，但不能越界。我用“笼中猛兽”来形容这种状态：笼子是边界，猛兽才是产能。

2.3 让AI会“用工具”：外部能力接入与沙箱安全

AI直接写代码只是“缰绳工程”的一部分，更关键的是让它具备“行动能力”。单纯在对话框里生成代码片段，和在真实项目里创建文件、修改代码、运行测试，这是两种完全不同的生产力水平。

现在的AI编程工具大多支持通过MCP这类开放协议接入外部工具。常见的接法包括：接入代码仓库操作能力（创建分支、提交代码）、接入终端执行能力（运行测试、运行构建）、接入项目管理能力（读取任务看板、更新任务状态）。这套东西的作用相当于给AI装了手和脚，让它不只是“出主意”，而是“能把活干完”。

接工具的时候我建议分三层安全措施：

1. 只允许AI操作当前项目仓库，禁止跨项目访问。
2. 所有外部命令必须在隔离沙箱里执行，沙箱内可以联网拉依赖，但无法访问生产环境网络。
3. 凡是涉及推送远程分支、修改Git历史、创建Tag的操作，必须经过人工批准。

事实证明，这三层安全措施不会拖慢多少速度，但对防止灾难性后果至关重要。零权限的AI只能“说”，有权限的AI才能“做”，而“缰绳工程”要的是有权限但被约束起来的AI。

我在搭建这套工具链的时候，采用了一款通用的智能体编排框架（你换成自己团队熟悉的也行），核心规则是：人的角色分为“调度者”和“审查者”，调度者负责往下发任务、审查者负责检查AI产出。AI始终在被分配的固定工作目录里干活，不存在“越权”的操作空间。整体体验和带一个不熟悉业务的实习生很类似，但你只需要说一遍就能配合上，且很少忘记要求。

3. 实操落地：一条从需求到百万行代码的生产链路

3.1 第一步：搭好仓库骨架，先定“不变的东西”

很多人让AI写代码是直接新建一个空目录，然后说“帮我搭个前端项目”。这是最大的错误：空仓库=无边界，AI会自己决定目录结构、依赖选型、编码风格。这套结构本身没有对错，问题在于它只符合AI当时的“偏好”，而你和整个团队未必认可，后续维护成本会直接爆炸。

正确做法是：人工先把“不变的东西”固定下来。包括：

• 技术栈：语言、框架版本、包管理器。
• 目录结构：业务模块放哪、公共代码放哪、测试放哪。
• 基础配置：ESLint、Prettier、TypeScript配置、CI配置。
• 数据层：表结构、ORM模型、迁移文件。
• 公共组件：UI库、工具函数、日志库。

这一步花的时间大约占总工时的30%，但换来的是后续70%工时内AI产出的一致性和可维护性。一句话总结：骨架由人定，血肉由AI填。

3.2 第二步：用“任务票”而非聊天框来驱动生成

搭建好骨架之后，不要打开聊天窗口和AI说“帮我继续写”，而是要像敏捷迭代管理一样建立任务池。我习惯在仓库里维护一个任务清单，每个任务写明如下字段（这是一份任务票模板，我踩过不少坑之后总结出来的）：

--- 任务ID: TASK-1042 标题: 实现用户详情接口 依赖: TASK-1038 (用户实体定义) 涉及文件: - src/modules/user/user.service.ts - src/modules/user/user.controller.ts - src/modules/user/user.types.ts 禁止修改: - src/config/* - src/database/entities/user.entity.ts 验收标准: - pnpm test -- user.service.spec.ts 通过 - GET /api/users/:id 返回结构符合 OpenAPI 定义 技术约束: - 使用 Repository 模式访问数据库 - 用户不存在时返回 404 和错误码 USER_NOT_FOUND --- # 任务说明 以 src/modules/user/user.types.ts 为入口，实现...

重点是“禁止修改”列表和“验收标准”列表。前者界定了AI的操作范围，后者是你判断任务是否完成的裁判依据。没有验收标准，AI就不知道“好”是什么样；没有禁止修改列表，AI很容易为了解决一个问题把不相关的代码改坏。

AI每完成一张任务票，就提交一条独立的Git commit，并且关联验收命令的输出。这样后续追踪问题很方便，万一出现回归Bug，直接回滚单任务即可，不需要翻整个迭代。

3.3 第三步：人在回路的检查点设计

“人在回路”这个词已经有点被说烂了，但缰绳工程里的“回路”有一层更具体的含义：不是每时每刻盯着AI，而是设置明确的检查点，只有通过检查点才允许AI进入下一阶段。我的建议是在三层设置检查点：

第一层，自动化检查。AI每完成一个小任务，立即触发测试、构建、类型检查、Lint。不通过就自动打回，AI自己根据报错信息修，修到通过为止。这个循环可以完全不需要人参与。

第二层，代码走查。每完成一个模块（比如10到20张任务票），人工做一次全面走查。主要看整体结构是否合理，有没有AI“自作主张”的设计修正，注释和文档是否清晰。这个走查不需要逐行读代码，重点是看模块之间的衔接和是否有隐藏的技术债。

第三层，里程碑评审。每完成一个大阶段（比如完成了用户系统、订单系统），做一次完整的功能验证和架构评审。这一步通常会让测试人员介入，从业务端到端地看系统能不能跑完整流程。

我自己的实践经验是：这三层检查点大约只占整体项目时间的20%，但能把事故率从高到吓人降到基本可控。如果不设置这三层，AI“看似顺利”的产出迟早会在某个深夜变成一场全面返工。

3.4 第四步：让测试当裁判，而不是靠肉眼review

AI生成代码的质量，靠肉眼是守不住的。原因很简单：AI生成的代码语法上几乎不会出错，看得见的问题不多，真正的问题都在边界条件和集成层面。所以缰绳工程里有一项硬要求：任何代码在进入人工评审流程之前，必须已经有自动化测试覆盖了核心行为。

我常用的策略叫“倒序编码”：先写测试，再让AI实现。具体来说，给AI一张任务票时，里面已经包含一组失败的测试用例（通常是服务接口的单元测试或集成测试），AI的任务是让这些测试全部变绿。这比让AI“自己写实现再自己写测试”好太多，因为“自己写实现再配测试”容易陷入无意义的自我验证——测试和代码共享同样的理解错误，出了Bug测不出来。

例如，我要实现一个“防重下单”功能，先写三个测试用例：同一用户重复下单同一商品返回错误；不同用户可重复下单相同商品；重复下单不创建新订单记录。AI拿到这些测试就会发现，它必须保证一个幂等性逻辑才能让所有测试通过。把验收标准具象化为测试用例，AI的自由度被细分到“行为层面”，而不是“语义层面”。

对于纯逻辑类模块，这套打法特别好使。对于UI类模块，测试相对难写，我的替代方案是生成一组带固定入参的Storybook快照，通过快照比对确认UI状态没有意外变化。本质上是一样的思路：用机器可执行的校验，替代人肉判断。

4. 三个月踩坑实录：常见问题与排查技巧

4.1 问题一：AI生成了看起来对但跑不通的“幻觉代码”

这是最普遍的问题。AI生成一段代码，逻辑看起来无懈可击，一运行就报错：导入了一个不存在的函数，或者调用了一个被废弃的API。这类问题就像“嘴替”一样，AI会一本正经地编造出看似合理的API签名。根源是训练数据里API的版本太混杂，模型对不同版本的接口记忆错乱了。

解决思路有几个。第一，重要API必须做成类型定义，放到仓库里并让AI严格引用，不让AI凭记忆去构造函数签名。第二，把关键依赖的版本锁死，并在项目文档里给出对应版本的API使用示例，减少AI“记忆混乱”的空间。第三，充分利用类型检查——TypeScript严格模式对幻觉代码的拦截效果远超预期，强制AI在生成代码时处理类型错误。

如果出现幻觉代码，不管是哪一类，我都会把相关API的真实用法写进AGENTS.md里，防止AI再次踩坑。这相当于给AI建立了一个“错题本”，比每次都从头排查高效得多。

4.2 问题二：上下文窗口被撑爆，生成质量断崖

当任务涉及文件变多、讨论轮次变长，AI的产出质量就会莫名其妙地下降。它开始忘记之前的约定，重复生成已经存在的函数，或者接口签名出现细微偏差。这是上下文窗口接近极限的典型信号。

我的处理方法是强制“分卷”：每轮对话只允许讨论一个任务票，完成即开新会话，新会话只加载context.md和当前任务票。新会话只关心当前任务的实现，不携带历史讨论的包袱。这样上下文里装的全是与当前任务强相关的信息，模型理解的精度自然上来。

同时，我还养成了一个习惯：每周清理一次context.md，把已经落地的决策删掉，避免无效信息占用宝贵的上下文空间。上下文不是越大越好，而是越准越好。

4.3 问题三：局部能跑，一合就崩

AI分模块生成时，单个模块单测都能过，但多个模块合并后系统跑不起来。原因通常是模块之间的协议不一致：A模块期望orderService.getById返回Order对象，B模块实际实现的是返回OrderDto。拆分任务的时候，接口契约没定死。

解决这个问题靠两层：模块边界定义和集成测试。模块边界要细化到“函数签名级”，比如在接口文件里定义getById(id: string): Promise<Order>，AI无论在哪张任务票里都通过同一份接口文件来引用最终产物，不自己二次定义。集成测试则保证从“用户发起请求”到“数据库落数据”的完整链路是通的，而不是只有单个函数能跑。

合并冲突也常见，AI在不同的分支里修改了同一个文件，而且互相不知道对方改了什么。我的方案是尽量控制并行Agent数量，同一文件的变更严格串行。虽然并行度下降了，但冲突率近乎归零，综合下来效率反而更高。

4.4 问题四：Agent无限循环，卡在一个死胡同里

AI写代码有时候会陷入死循环：改测试不过，再改还是没过，来回几轮一直报同一个错，甚至越改越偏。这相当于它在一堵墙上反复撞头。通常原因有两个：一是它没有正确理解报错信息，二是它为了“修好”一个失败测试，采取了错误方向的重写。

我的止损办法是设定最大重试次数，默认3轮。超过3轮还没通过，直接把任务打回给人，人判断是任务描述不清楚还是技术方案本身有问题，而不是让AI一直耗下去。从实际效果看，超过3轮还不通过的，AI再跑10轮也基本过不了，人工介入才是最高效的出路。

还有一种特殊死循环：AI调用外部工具出错，比如沙箱命令执行失败、测试框架报环境相关错误，AI会自动生成“修复环境”的代码，结果越修越大。出现这种情况，我会考虑是不是沙箱环境本身有问题，先人工把环境修好再继续，别让AI承担运维工作。

4.5 常见问题速查表

这个表格不是“理论速查”，而是我把几十次项目事故逐一记录后整理出来的高频故障卡。你也可以在自己团队里积累一张这样的卡，比任何方法论都好使。

5. 一些更底层的思考：这套方法能复用到什么程度

我听到过一种质疑：“100万行代码靠AI写出来，但维护还是要靠人，这种代码靠谱吗？”答案是：取决于你对“靠谱”的定义。如果“靠谱”意味着“零技术债”，那确实没人敢保证；但如果“靠谱”意味着“可追踪、可测试、可修复”，那么缰绳工程的产出是完全达标的。关键是它把每次AI生成都限定在可验证的小步骤里，任何一个环节出问题都能定位到具体任务票和具体逻辑块，不会出现“改一行代码崩整个系统”的恐怖故事。

从更广的视角看，这套方法论不只适用于编程。我尝试过把它迁移到“文档生成”“运营素材批量产出”“数据分析报告自动化”里，底层逻辑同样成立：先把大目标拆成有验收标准的小任务，再限制执行者的操作边界，最后用自动化检查兜底。核心永远是“控制还是被控制”的问题。工具越强大，控制体系越需要提前建好。

我个人实操中的体会是：AI工程不是“用AI替代人类工程师”那么简单，而是“每个人类工程师都变成了一个团队的指挥官”。原来一个人只能同时管好自己手头的逻辑，用了缰绳工程后，一个人可以同时指挥多个AI的执行流，像开了一家“一人软件公司”。这种转变对个人的工程素养要求不降反升：你不再需要是打字最快的程序员，但你必须是想得最清楚、拆得最明白、验得最严格的那个人。

最后再分享一个小技巧：建立一套“任务票模板库”。我手里有几十张经历过实战打磨的任务票模板，按类型分——新增功能、修Bug、重构、性能优化、测试补充。每次要开工，复制模板改参数即可，不用每次都从零写。这比任何AI提示词技巧都管用，因为提示词是一次的，任务票模板是复利式的。你的团队如果也能把踩过的坑沉淀成模板，那下一次做出又一个“百万行代码”项目时，很可能只需要更少的人、更短的时间。