代码生成越来越廉价，为什么拼尽全力的战术勤奋反而追不上技术的翻页？当“只要努力就能成”的信仰受挫，技术人的焦虑往往源于浮躁叙事下的三大幻觉。
穿越周期的定力，来自于在失序中“看见终局”。本分享将从 AI 终局与技术人终局两个视角出发，剖析如何将死知识升级为可执行的测试集、如何驾驭多目标求解的 Looper，以及如何在端到端小团队中重筑护城河。

老兵的大脑里天然刻着确定性与因果律，但新一代技术人却面临着“浅层滑行”的危机。在满世界追求效率的时代，我们如何坚守工程定力，避免技术人沦为毫无深度的“提示词发射器”？

演讲提纲

1. AI 时代的三大幻觉与解法

努力为什么突然追不上了？

• 幻觉一：有求必应的成长丧失
• 幻觉二：无所不能的菜鸡互啄
• 幻觉三：唯快不破的错误加速

2. 看 AI 终局，寻定海神针

• 信噪比的“精益求精”
• 知识库 VS 测试集
• 构建 Looper 的思考方式

3. 看“人”终局，构建护城河

• 左移右移，兼顾效率与创新
• 上游下游，更聪明的协作者
• 构建分层矩阵，突破未知
• 拥抱端到端小团队

4. 总结：让每一代都懂“为什么”

当 AI 承担越来越多的实现工作，以固定职能分工定义的“程序员”角色正在变化。面对难以保证一年后仍然适用的职业建议，技术人应如何选择下一步？本次分享提出 Exploration > Exploitation，把探索新角色与工作方式放在局部优化之前，以 DHH 两次访谈中的实践变化承接这一判断，并结合团队实践展开三种尝试：从匠人到厂长，拓展系统视野、建设 Managed Agents 平台；从工程师到顾问，以算法工程师贯穿金融场景销售到服务的案例，讨论领域理解、减少交接与避免外包化；放开想象，重新尝试过去搁置的个人目标。

演讲提纲

1. 从“程序员”到“AI 时代的技术人”

• AI 承担越来越多的实现工作，传统职能边界正在被重新定义
• 当“写代码”不再是技术人的核心稀缺能力，我们该如何重新定位自己？
• Exploration > Exploitation：优先探索新的角色与工作方式，而非追求最大化短时产出

2. 从匠人到厂长：从写代码到构建系统

• 技术人的视野如何从单点实现走向系统经营
• 建设 Managed Agents 平台，让 AI Agent 成为可管理、可复用的生产力
• 从“亲自做得更好”转向“让整个系统做得更好”

3. 从工程师到顾问：从交付技术到理解业务

• 算法工程师贯穿金融场景从销售到服务的实践
• 为什么领域理解会成为 AI 时代技术人的重要能力
• 减少角色交接，让技术人员直接连接业务价值，避免工程能力进一步“外包化”

4. 放开想象：重新定义自己的下一步

• 不再执着于一份固定的职业路径和能力清单
• AI 降低了过去很多“想做但做不到”的门槛
• 重新尝试那些曾经搁置的个人目标，探索技术人新的可能性

实践痛点

• 产出速度与维护能力不匹配。 AI 能快速生成大量代码，重复实现、复杂组件和错误模式也可能随之扩散。测试、审查和平台建设需要持续投入，并占用短期功能开发时间
• 岗位边界扩大，但知识不会自动补齐。 从局部实现走向完整交付，需要拓展系统知识；从工程师走向顾问，需要接触业务现场、建立信任并判断问题的价值
• 一人贯穿流程，也容易成为新的瓶颈。 减少交接能够保留上下文，但如果关键判断和日常服务都依赖一个人，工作量和维护压力仍会持续增长，需要平台支持和清晰的责任范围
• FDE 容易做成一次性定制。 如果每个场景都从头实现、不断追加需求，却没有形成可复用能力，AI 提效可能只换来更多接单与维护工作
• 探索有成本，方法也会过时。 新尝试未必马上产生回报，工具变化还会让已有方法需要重做。需要结合个人处境平衡当前交付与探索投入，并根据反馈调整方向

前沿亮点

• 将 AI 提效放到职业探索中重新审视。 以 DHH 的实践变化为引子，讨论经验和建议的适用条件，将关注点从原岗位上的效率优化，延伸到职责范围、工作方式与个人目标的探索
• 呈现平台建设与领域实践之间的联系。 将“厂长”和“顾问”两段串联：前者建设 Managed Agents 平台，后者利用平台与领域经验贯穿销售到服务。通过金融场景案例，说明减少跨职能交接如何扩大个人能承担的工作范围
• 正面讨论 FDE 的外包化风险。 把问题定义、结果责任、可复用能力和后续维护纳入讨论，帮助听众判断自己的角色变化是否真正增加了解决问题的能力

听众收益

• 获得一个审视职业投入的视角：识别自己是在优化熟悉的工作，还是在探索新的问题与职责，为下一步选择提供依据
• 理解三种可以尝试的转变，以及各自需要补充的能力：系统与软件工程知识、领域理解与业务判断、对个人目标的探索和验证
• 通过 Managed Agents 与金融案例，理解平台能力、领域经验和减少交接之间的关系，思考如何在自己的团队中扩大负责范围
• 获得判断 FDE 与定制交付边界的几个问题，识别缺乏复用、无限追加需求和持续依赖个人服务的风险
• 带着一个自己的探索问题离场，找到一个可以开始、能够获得反馈的具体行动

AI Coding 压缩编码成本后，研发瓶颈开始转向需求、设计、验证和生产责任。我们提出“人站在 V 模型两端、Agent 执行中段”的 Human-on-the-loop 模式：用研发六环划定自治半径，以 SpecX 将专业判断前置为 Spec、后置为 Evidence，再通过 Loop Ownership 重构团队责任。目前 1～3 环已推广，4 环跨仓设计和 5 环测试交付完成穿刺，覆盖 400+ 需求、Skill 调用 1 万+。演讲还将复盘全流程自治、RAG 替代 Spec、平台包办 Agent 和新人训练被跳过等踩坑。

演讲提纲

1. AI 接管执行，人的责任为何上移：分析编码提速后出现的意图税、上下文税、验证税和稳定性税，以及 Developer、Architect、QA、SRE 和管理者的价值中心如何变化

2. V 模型与研发六环划定人机边界：人在左端定义目标、约束和风险，在右端定义证据、验收和发布决策；Agent 承担中间规划、生成、检查和修复，并从实现级逐步扩展到设计、交付和运行级

3. SpecX 承接 Human-on-the-loop：SpecSpace 将专业判断沉淀为结构化工程上下文，SpecFlow 与 Harness 负责编排执行，Eval、Gate 和运行反馈负责验证、回放与失败学习

4. 团队转向 Loop Ownership：领域团队拥有业务结果和验收标准，平台提供工程底座，治理团队定义自治与生产边界，团队从逐步审批转向监督指标、处理异常并对完整闭环负责

5. 真实踩坑与人才重构：复盘生成量不等于交付收益、长链路难诊断、RAG 不等于可执行知识、平台包办导致责任弱化，以及 AI 可能跳过新人判断力训练等问题

实践痛点

1. 自治与确定性的冲突：Agent 越自由，泛化能力越强，但执行越难复现和诊断；约束过多又容易退化为传统脚本

2. Spec 成本与变化速度的平衡：Spec 太轻无法约束 Agent，太重则产生新的文档负担，需要在真实失败中增量建设

3. 可信度与验证成本的取舍：Eval、门禁和证据链可以降低风险，但会增加算力、等待和维护成本，需要按风险等级配置

4. Human-on-the-loop 的能力退化风险：人不再参与每一步后，可能失去系统细节和故障感知，尤其需要重构新人培养与异常演练

5. 平台复用与领域责任的张力：平台统一能力可以降本，但不能包办业务 Agent，否则领域团队容易失去结果所有权

演讲亮点

1. 将 V 模型重新解释为人机职责图：不同于主要关注模型能力、代码生成率和工具调用的方案，本实践先明确人在定义端与验证端的责任，再用研发六环逐层扩大 Agent 的自治半径

2. 用“Spec—Harness—Evidence”将专业判断工程化：区别于单纯建设 RAG 或 Prompt 模板，SpecX 让知识能够约束执行、结果能够被证据验证、失败能够回流为新的 Spec、Eval 和 Harness

3. 将 Human-on-the-loop 落实为 Loop Ownership：为每条闭环明确 Owner、自治级别、证据标准、异常接管点和学习机制，使个人 AI 提效能够转化为团队能力

听众收益

1. 可以了解一套分析技术人责任迁移的框架，并参考 V 模型与研发六环判断哪些场景适合自动执行、哪些仍需审批或人工接管。同时可将 Spec、Harness、Eval 和 Loop Ownership 作为研发 Agent 方案设计的检查清单

2. 分享中的真实踩坑，也可为团队评估局部提效、知识建设、组织责任和新人培养问题提供案例参考