第 17 章 · 别一上来就写代码
老板先看这一句： 看到团队要花几周搭一套「完整系统」,先喊停——那很可能是在为还没验证的方向烧钱。正确的顺序是先用开箱工具(几天)快验价值,方向对了再定制,真要上生产才工程化。你该问团队:这事能不能先用现成平台三天跑通给我们看?别一上来就批重金自研,验证没过,钱就打水漂了。
一个白写了三周的框架
有个刚转 Agent 落地工程师的后端工程师,接了个「合同条款问答」的 PoC。他手很快,拿到需求第二天就开工了——自己搭向量库、写检索、封装 API、做了个前端页面,一套工程化架构干得漂漂亮亮,写了三周。
演示那天,业务方看了两分钟就说:「这个问答我们其实想要的是能直接圈出合同里有风险的那句话,不是一问一答。」——他理解的场景,和业务方要的,根本是两回事。三周的框架,推倒重来。
问题不在他技术差,恰恰相反,他技术太好,好到一上来就奔着「造一个耐用的系统」去了,却跳过了「先确认这条路对不对」。 在 PoC 阶段,写代码往往不是最快的验证方式,反而是最慢、最贵、最舍不得推翻的那个。
Agent 落地工程师戴上架构操盘手这顶帽子,第一条纪律是:别一上来就写代码。 先问「有没有不写代码也能验证的办法」,验证通了、方向对了,再决定要不要、以及在哪里投入工程。这一章给你一条三层路径,教你把力气花在刀刃上。
跨境家居老板老陈要是听工程师说「我先搭三个月框架」,就该立刻问:能不能先用现成平台三天做出个能看的 Demo?跑通了再谈重金,跑不通钱省下了。
三层路径:快验 → 定制 → 工程化
同一个需求,有三种造法,代价和用途完全不同。关键是按顺序来,能停在前一层就别进下一层。
第一层:开箱工具快验(1–3 天)。 用 Dify、Coze、n8n 这类平台,拖拽就能搭出一个能跑的流程。目标不是好看、不是耐用,是最快验证「这条路走得通、业务方认这个方向」。第 12 章那个案例,第一版就是用开箱工具三天跑通的。这一层做出来的东西丑、糙、扛不住量,没关系——它的使命是拿到「方向对不对」的答案,答案拿到就该功成身退。
第二层:Vibe Coding 定制(几天到一两周)。 开箱工具总有做不了的地方:一个特殊的交互页面、一个平台不支持的小工具、一段定制的处理逻辑。这时候用 Cursor、Codex 这类 AI 编程工具,以自然语言驱动,快速补上这些定制件。它比纯手写快得多,又比开箱工具灵活——是「快验」和「工程化」之间的过渡带。
第三层:工程化(按需,通常在验收后)。 当 PoC 已验证价值、要走向生产——需要可维护、可扩展、能扛真实流量、能长期演进——才动用 LangGraph、LlamaIndex、FastAPI 这类真正的工程栈,把前两层验证过的东西,重写成一个能上生产、能交接的系统。
一句话记住:前两层是为了「验证值不值得」,第三层才是为了「做得住、传得下去」。 那位工程师的错,是直接从第三层起步。
一张工具选型地图
哪层用什么、什么时候升层,做成一张地图,选起来不纠结。
| 层 | 典型工具 | 用来干什么 | 什么时候用 | 升到下一层的信号 |
|---|---|---|---|---|
| 快验 | Dify / Coze / n8n | 拖拽搭流程,跑通核心 Case | 刚拿到方向,要验证假设 | 方向已确认,但开箱工具做不了某些定制 |
| 定制 | Cursor / Codex 等 Vibe Coding | 补开箱工具做不了的页/工具/逻辑 | 需要定制交互或特殊处理 | 已验收,要上生产、要可维护 |
| 工程化 | LangGraph / LlamaIndex / FastAPI | 可维护、可扩展、上生产 | PoC 通过验收,走向 MVP/生产 | —— |
选型不是一次性决策,而是一条随信号升级的路。 大多数 PoC,在快验和定制两层就能完成验收;真正需要爬到工程化的,是那些已经证明了价值、要长期跑下去的项目。
不管在哪一层,都建议同步维护一张技术架构图(接入层/编排层/智能体层/能力层/数据层/横切),它既是当前施工图,也是升层时的路线图。模板见附录 C。
工具名会变，选型问题不会变。更稳妥的问法是：
| 路径 | 不变的问题 | 工具只是例子 |
|---|---|---|
| 快验 | 能不能 1–3 天把核心流程跑通，让业务方看到方向？ | Dify / Coze / n8n / 其他低代码 Agent 平台 |
| 定制 | 开箱工具缺的交互、集成、脚本能不能快速补齐？ | Cursor / Codex / Claude Code / 其他 AI 编程工具 |
| 工程化 | 能不能多人维护、可观测、可回滚、权限隔离、稳定运行？ | LangGraph / LlamaIndex / FastAPI / 企业内部平台 |
什么时候必须进入工程化？看六个信号：
- 已有真实用户连续使用，不再只是演示。
- 接入了生产系统或客户数据。
- 需要权限隔离、审计日志和回滚。
- 每天调用量、成本或延迟开始影响业务。
- 需要多人维护，不能只靠 Agent 落地工程师的个人电脑和个人账号。
- 业务方要把它纳入正式流程或 SLA。
快验阶段可以欠一些债，比如界面粗糙、脚本临时、监控简陋；但进入 MVP 前，权限、日志、评估、回滚、成本监控这些债必须还。
工具选型之前，先画企业上下文地图
Agent 的效果上限，往往不是模型决定的，而是它能否取得完成任务所需的真实上下文。不要一听“数据不完整”就先建大而全的数据平台；只补齐当前业务能力真正需要的部分。
| 上下文层 | 要连接什么 | 先问清楚 |
|---|---|---|
| 业务状态 | ERP、CRM、OMS、WMS、广告平台中的实时状态 | 哪个系统是事实源，数据延迟能否接受 |
| 经营数据 | 订单、利润、库存、广告、客户与供应链指标 | 口径是否统一，谁负责解释 |
| 企业知识 | SOP、规则、产品资料、历史案例与岗位经验 | 版本如何更新，过期内容谁下线 |
| 系统接口 | 查询、创建、更新、通知和审批动作 | 是只读、建议还是允许写入 |
| 身份权限 | 用户、角色、租户、数据范围和操作权限 | 谁能看什么、做什么，如何审计 |
选工具只是最后一步。先确定经营问题、目标流程和必要上下文，再选择最轻、最容易维护的实现方式。
Agent 落地工程师选型的三个判断
工具眼花缭乱,但 Agent 落地工程师选型时其实就盯三件事,别被新框架带跑。
- 够用就好,别为「更强」升层。 开箱工具能验完的事,别为了「显得专业」去写框架。技术栈的高级程度,不是交付水平的证明。
- 看能不能交接,不只看能不能跑。 第三层工程化的一个隐藏目的,是让东西能被别人接手运营(第 21 章)。选型时就要想:这套将来谁来维护、他 hold 得住吗?
- 成本、延迟、合规一起算。 模型和工具的选择,不只看效果,还要看单次成本、响应延迟、数据是否合规出境。这些在快验阶段就该心里有数。
📍 场景示例：老陈的选品周报，先用开箱工具三天跑通
老陈的选品 1 人，人肉盯 6 平台，竞品周报要 4h/周，差评发现滞后约 2 天。FDE 接到「自动选品周报」需求，没立刻写框架，而是先用 n8n 拖一个开箱流程：定时抓 6 平台数据 → RAG 生成中文周报，三天就跑通给老陈看。方向确认后，再用 Cursor 补一个「差评聚类」定制件；直到要上生产、要权限隔离才升到工程化。省下的，是「未验证就自研三周」可能白干的风险。
| 维度 | 改造前 | 改造后 |
|---|---|---|
| 周报耗时 | 4h/周（人工） | 开箱工具 3 天跑通，自动出 |
| 技术路径 | 一上来就自研框架 | 快验(n8n)→定制(Cursor)→工程化 |
| 试错代价 | 方向错 = 白写 | 丑版先验方向，省重金 |
| 差评发现 | 滞后约 2 天 | 周报内直接标红 |
老板决策点： 听到「我先搭三个月框架」就喊停——先问能不能用现成平台三天跑通给你看。 ——对应 → L3
常见坑
- 一上来就工程化。 跳过快验直接写框架,方向一错三周白干。
- 停不下来,层层往上爬。 快验能收工却非要升到工程化,为不需要的耐用性付代价。
- 只顾跑通,不画架构图。 没有架构图,升层和交接时全靠脑子记,越到后面越乱。
- 选型只看技术光鲜。 挑最火的框架而不是最合适的,埋下没人能维护的坑。
本章产出
老板行动点： 看到团队要花几周搭「完整系统」先喊停。问一句:这事能不能先用现成平台三天快验给我们看?验证没过就批重金自研,钱打水漂。该省的工程化投入先省,但快验阶段欠下的权限、日志、回滚这些债,进 MVP 前必须还——这部分不能省。
往交付包里放一张「工具选型地图 + 当前层架构图」:
为你的 PoC 标出现在处在三层路径的哪一层、用了什么工具、什么信号出现才升下一层;再照 附录 C 画出当前这一层的技术架构图。这张地图让你(和小队)始终清楚:力气该花在验证,还是花在工程。
成熟度自检
- [ ] 我能按「快验→定制→工程化」三层路径,为 PoC 选对起点、不过早工程化(→ L3)
- [ ] 我能画出当前层的技术架构图,并说清升到下一层的触发信号(→ 巩固 L3)