本次分享将结合小红书技术团队在“产品工程师（PE）”实践中的探索，复盘 AI 时代技术人能力结构的变化：当 AI 不断降低技术实现的门槛，技术人的价值正在从“把技术做好”转向“把事情做成”——不仅要具备技术能力，还需要建立 Leader 思维，以及理解业务、判断价值的能力。作为一名亲历“客三消”唱衰周期的技术人，我将结合自己在技术浪潮和组织变化中的实践，聊聊这个转变具体意味着什么。

演讲提纲

1. 从“客三消”说起：亲历的行业周期

• 客户端需求曲线复盘：繁荣 → 全网疯传“客户端三年消失”→ 人才断层 → AI 时代需求回暖
• 没有人能一直站在技术浪潮之巅，我一直在往“更靠近结果”的方向做
• 真正稳的不是技术栈，是“把问题解决”的惯性

2. AI 冲击的背后：技术人价值的重构

• AI 让“写出来”变廉价，“写得好”不再是壁垒
• 小红书“产品工程师（PE）”给出的答案：衡量标准从“代码质量、按时交付”变成“业务结果”
• 新的能力公式：技术能力打底，Leader 思维 + 业务/价值判断决定上限

3. Leader 思维：建立 Agent 团队

• 认知转变：过去 Leader 思维是管理者专属，现在你指挥的是一群 Agent——你就是 Team Leader
• 建立 Agent 团队：从执行者变成设计者
• 管理能力迁移：管人与管 AI 的异同，靠机制不靠自觉

4. 业务思维：理解与价值判断

• AI 能高效做一件事，但不负责“该不该做这件事”
• 判断力：做减法更重要

5. 技术人靠什么赢

• 从“把技术做好”转向“把事情做成”

实践痛点

• AI 冲击：古法时代建立的价值体系将会重塑，经验过于资深反而容易被淘汰
• Leader 思维不是喊口号：从“自己干得好”到“让别人/Agent 干成”，是很多技术人跨不过去的坎
• 业务/商业判断力没有捷径：它不像技术能力可以刷题速成，只能在一次次“把事做成/搞砸”中长出来

演讲亮点

• 一手的行业周期视角：从“客三消”到今天，个人真实经历完整穿越了行业的低谷与反弹，不是旁观者的二手分析
• 管理能力迁移的独特洞察：管人和管 AI 的异同，把十年技术治理经验（治代码→治团队→治 AI ）串成一条方法论主线，可迁移、可复用

听众收益

• 理解 AI 时代技术人的核心竞争要素：为什么“把技术做好”不够，价值坐标如何迁移到“把事情做成”
• 掌握 Leader 思维的落地方法：如何建立并管理自己的 Agent 团队，以及"靠机制不靠自觉"的具体做法
• 获得穿越技术周期的心法：在技术浪潮起落和组织变化中，如何不掉队、不被单一技术绑架

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