Proud Tech Summit 2026：代码生产廉价化，知识为何昂贵

Proud Tech Summit 2026 由 Starian 与 Softplan 联合举办，八小时的议程避开了互联网上泛滥的 AI 对话演示，把镜头对准了遗留关系型数据库、脆弱集成、财政约束，以及让模型真正服务客户所需的基础工作。据参会者整理的线上直播内容，这场活动的核心命题可以浓缩为一句话：生成代码已经变得又快又便宜，而理解业务规则、编写技术契约、设计回归测试，依然是昂贵的人类劳动。

工具在加速，理解没有

Starian 的 Carla Souza 在开场中指出一个明显错位：工具迭代速度陡增，但吃透业务逻辑、验证系统所需的时间，仍然是彻底的人类时间。Softplan 的 Guilherme Brasil 用一个对照实验把这一点讲得很直白——同一个 LLM 模型，先要求写一段 32 词、包含 5、10、15、25、50 五个数字的开场白，模型吐出的是关于里程碑与未来影响的空洞套话；当他补上真实语境（峰会第五届、公司十年、女儿十五岁生日、结婚二十五年、自己五十岁），输出立刻变得直接且有幽默感。模型没变，变的只是输入里携带的上下文。

Luis Fausto 引用的 Gartner 与 McKinsey 市场调研给出了量化印证：约 77% 的企业仍困在早期试点与概念验证阶段，只有 23% 真正把智能体系统部署进了生产环境。瓶颈不在模型能力，而在运营条件——一个智能体要在生产环境跑起来，需要明确的责任人、显式的服务等级协议（SLA），以及能从错误中恢复的可靠回滚机制。

Orbit 的三周冲刺：先写新闻稿，再写代码

Jean Roloff 介绍了 Starian 智能体平台 Orbit 的开发过程，整个项目在为期三周的高强度冲刺中完成。写代码之前，团队先套用亚马逊的 Working Backwards 方法：假设产品已经发布，先把新闻稿和内部 FAQ（PR/FAQ）写出来，以此对齐客户需求与预期业务成果，然后才打开编辑器。

开发环节强制执行规格驱动开发（SDD）。团队不写开放式提示词，而是先定义数据契约、接口和单元测试，再让 AI 生成代码。最终项目累计超过 20 万行代码，自动化测试覆盖率超过 90%。另一个关键决策是克制：他们没有试图一次性上线架构中规划的全部十五个微服务，而是在 Contato Seguro 产品中切出一个只负责举报分诊的垂直切片，先部署到生产环境收集真实数据，再向其他模块扩展。

Working Backwards（逆向工作法） 是亚马逊内部广泛使用的新产品定义方法：不从功能清单出发，而是先假设产品已经成功发布，撰写一篇面向客户的新闻稿（Press Release）与配套的内部常见问题（FAQ），回答“客户是谁、痛点是什么、为什么值得兴奋”等问题。只有这些叙事能被清晰写出来，团队才进入技术设计。它的价值在于把讨论从“我们能做什么”拉回“客户需要什么”，并在写第一行代码前暴露需求歧义。Orbit 团队用它来对齐客户需求与业务成果，正是把这一方法论从消费产品延伸到了智能体平台的开发语境中。

规格驱动开发（SDD，Spec-Driven Development） 指的是在让 AI 生成代码之前，先以机器可读且结构化的形式定义数据契约、接口签名和预期测试，再把这些规格作为模型的输入约束。它与开放式提示词的关键区别是：规格本身就是可验证的工件，生成结果必须满足已声明的接口与测试，而不是由人反复阅读散文式提示词来判断。这样做的收益是生成过程可审计、可复现，失败时也能定位是规格缺陷还是实现偏差，而非在不可控的自然语言输入里追责。

垂直切片（Vertical Slice） 是敏捷交付中的一种切分策略：不按架构层（数据库、服务、前端）横向推进，而是沿一个完整业务流程纵向切出一小条，从入口界面到数据落库全部打通并部署到生产。Orbit 只上线举报分诊这一条链路，而不是同时铺开十五个微服务，目的就是尽早获得真实流量与真实故障，用生产数据校准后续设计，避免在孤立环境中积累假设。

Softflow：220 名工程师与四道人工闸门

Softplan 面对的问题不是 AI 采用率不足，而是自定义脚本和提示词在 220 多名工程师之间无序扩散，导致代码库难以协同维护。Pedro Escobar 提出的 Softflow 框架基于 Orchestrator-Workers 模式，包含十一个阶段，核心是四道强制检查点——执行会暂停，直到开发者确认生成结果。

闸门	智能体自动化动作	人工验证内容
Gate 1	读取工作项并撰写正式技术规格（SDD）	规格批准前不写任何代码
Gate 2	子智能体扫描 diff 中的安全、性能与架构问题	开发者逐条评估并决定修复或驳回
Gate 3	创建分支并运行自动化集成测试	合并进主仓库需人工批准
Gate 4	准备收尾并核验业务标准	人工确认业务需求是否真正解决

现场演示中，Escobar 展示了一个针对 IBM Jazz RTC 遗留集成的缺陷修复：API 返回空的所有者字段，智能体通过 MCP 协议调用检查工作项并实现补丁。在开合并请求之前，一个审查子智能体标记出某行日志缺少对应单元测试，团队当场补上调整，随后全部测试通过并完成合并。这类细节说明，闸门不是形式主义，而是把人类的判断力安放在错误代价最高的位置。

Orchestrator-Workers（编排者-工作者）模式 是多智能体系统的一种经典拓扑：一个编排智能体负责拆解任务、分配子任务、汇总结果并决定下一步，多个工作者智能体各自在受限的职责范围内执行具体动作。它的工程意义在于把复杂流程显式化——编排层可以记录状态、插入检查点、限制工作者可访问的工具，而不必依赖单个模型在一次长对话中记住全部约束。Softflow 的十一个阶段与四道闸门，本质上就是把编排逻辑从模型内部搬到流程层面，使人类能站在固定位置审查。

MCP（Model Context Protocol） 是一个开放协议，用于让语言模型以标准化的方式访问外部工具与数据源，通常由客户端（模型侧）与服务器（数据/工具侧）两端组成。服务器向模型声明可用的工具列表与参数结构，模型通过协议发起调用并接收结构化结果。相比把数据库地址和凭据直接交给模型，MCP 把权限边界收敛到服务器实现里，因此可以在协议层做参数校验、访问审计和能力裁剪，这正是后文中双层安全模型得以成立的前提。

范围受控的 diff 审查 是 AI 辅助开发中常被低估的工程实践：子智能体只读取本次变更的 diff，而不是整个代码库，从而在有限的上下文窗口内聚焦于安全、性能与架构风险。它的局限是需要人类判断哪些问题属于本次变更引入、哪些是既有债务，这也是 Softflow 把“逐条评估并决定修复或驳回”保留为人工动作的原因——自动化负责发现，人负责归因与取舍。

1Doc：把市政服务搬进 WhatsApp 的工程约束

Rafael Gomides 与 Amanda Aragão 分享了 1Doc 通过 WhatsApp 交付市政服务的案例（Limeira 的 LIA 与 Florianópolis 的 TIA）。选择 WhatsApp 是看中其普及度，但随之而来的是一组具体的架构约束。

日常聊天中，人们发送碎片化消息、语音，还会随时切换话题，这与行政工作流并不天然匹配。解决方案是在对话中嵌入结构化表单，并让智能体把复杂边缘案例直接路由到线下服务台。安全层面，手机号不构成法定身份，因此 1Doc 把认证解耦：市民点击临时链接登录官方网页平台，密码和个人数据不会在聊天记录中流转。市政工单的创建也不依赖第三方即时通讯应用的可用性——记录会先事务性地写入中央数据库，之后才向用户发送通知。

预算与风险控制同样被产品化：管理员可以按需关闭特定服务，系统在合同配额的 50%、70%、90%、100% 处自动告警；一旦触及上限，AI 处理会干净地停止，请求回落到标准人工支持队列。

MCP Server：让 AI 查库但不许写库

Diogo Noschang 处理的是另一个高频难题：如何让模型查询企业数据库，却不暴露敏感记录、不引发意外变更。遗留数据库承载着数十年的隐式规则和缩写表名，直接把原始 schema 暴露给语言模型，误读几乎必然发生。

Starian 的做法是在模型与公司数据库之间放置一个 Python 编写的 Model Context Protocol（MCP）服务器，安全分两层执行。逻辑层负责参数清洗、阻断 SQL 注入、拒绝过宽查询（例如试图无过滤转储整张表的提示）；物理层的数据库连接用户被严格限制为 SELECT，没有任何 INSERT、UPDATE、DELETE 授权，即便模型出错也无法改动数据。该服务器还按需管理上下文：不每次加载完整 schema，只提供回答特定指标所需的工具。在 Projuris Empresa 的 Starian Performance 360 框架中，这套设置统一了 Jira、SonarQube、GitLab 与 Windsurf 的查询，记录到合格交付吞吐量提升 27.3%，返工率为 17.6%。

红牛车队与 Lovable：两个极端的速度样本

Lucas Leung 的分享展示了算力光谱的另一端。比赛周末，Oracle RedBull Racing 在 Oracle Cloud Infrastructure（OCI）上拉起运行超过 500 个 ARM CPU 的 Kubernetes 集群。当黄旗或安全车改变比赛条件时，系统每秒执行峰值达百万次的蒙特卡洛模拟，评估约六百万种场景以判断进站可行性。这套系统支撑了 Max Verstappen 在迈阿密大奖赛的表现：从第九位发车、硬胎起步、在干净空气中延长第一段、后段换上中性胎并夺冠，进站墙上的决策直接由这些实时概率模拟引导。

Alexandre Messina 则展示了 Lovable 与 Vibe Coding 的另一极。Amicci 的 Amosview 是一个样品管理工具，由一名运营专员在两天内构建，绕过了向中央 IT 提交工单的瓶颈。验证产品概念、搭建概念验证、组装部门级小工具，这类场景的速度优势显而易见。但边界同样清晰：提示词生成的界面能处理初始交互，却解决不了承载十年隐式业务规则的遗留数据库、异步队列、审计与严格会话控制。在 Lovable 里用 Supabase 加 Stripe 一个下午就能搭出一个 SaaS，而在 Softplan 和 1Doc 的日常工程中，难题是让自动化与遗留系统共存——那里数据损坏的风险直接触及法律与税务合规。

蒙特卡洛模拟 在赛车策略中的用法是：对剩余比赛的每一段（圈数、轮胎磨损、可能的黄旗或安全车）反复采样随机事件，运行成千上万乃至数百万次，统计每种进站时机对应的完赛名次分布。单次模拟只给出一个可能世界，只有海量重复才能得到概率意义上的最优决策。这解释了为什么比赛周末需要超过 500 个 ARM CPU 的 Kubernetes 集群——算力不是在训练模型，而是在可用的决策窗口（通常只有几十秒）内把概率分布算得足够稳定。

Vibe Coding 指以自然语言描述意图、由模型直接生成可运行界面与逻辑的开发方式，强调快速迭代和低门槛，而非严格的规格与测试先行。它的优势在于把“提出想法”到“看到东西”的间隔压缩到小时级，让业务侧人员绕过 IT 工单流程验证概念。但它的产出通常缺少事务边界、并发控制、审计痕迹与权限模型，因此适合原型、演示和部门级小工具，不适合承载法律与税务合规要求的核心系统——这正是文章把它与 Softplan、1Doc 的工程实践对照呈现的原因。

留下的是什么

把这场峰会的多个分享交叉来看，共识相当稳定：代码生成已经成为流程中快速且廉价的一环，继续消耗时间的是那些一直消耗时间的事——理解业务规则、在实现之前起草技术契约、编写能捕获回归的测试。MCP 协议值得深入研究，规格应该写在索要代码之前。其余的部分，大多只是噪音。