---
title: "日产万行业务代码背后，我们真正修的是一条 Harness 公路"
url: https://www.agilean.cn/insights-new/65/
updated: 2026-08-17
description: "吴穹博士在全球AI生态与创新峰会的演讲整理：AI 让个人写代码更快，组织交付却未必跟上。文章说明 Harness 作为 AI 软件工程的交付底座，需要逐步补齐测试、数据、日志、环境、验收和计划等能力。"
publisher: "Agilean（爱捷软件开发（深圳）有限公司）"
language: zh-CN
---

吴穹博士在全球AI生态与创新峰会的演讲整理：AI 让个人写代码更快，组织交付却未必跟上。文章说明 Harness 作为 AI 软件工程的交付底座，需要逐步补齐测试、数据、日志、环境、验收和计划等能力。

# 日产万行业务代码背后，我们真正修的是一条 Harness 公路

原创 作者：吴穹 发布于 2026/8/17

导语：前几日，吴穹博士在全球AI生态与创新峰会上分享了主题为《日产万行业务代码背后的 Harness 之路》的演讲，本文根据演讲内容整理。如您想获取演讲PPT，请至我们的官网下载：https://www.agilean.cn/events/ 。

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-2.jpg)

*演讲主题：日产万行业务代码背后的 Harness 之路*

很多团队现在都有一个很微妙的感受：

工程师确实变快了。

代码解释、代码生成、单测补齐、接口联调、文档整理，过去要花很久的事情，现在 AI 可以先把一大半脏活干掉。

但回到组织层面，事情没有那么乐观。

个人速度上去了，组织交付却不一定跟上。甚至有些团队会发现：提交更多了，返工更多了；代码更快了，质量压力更大了；每个人都觉得自己提效了，但需求排期、联调、验收、发布和线上风险，并没有同比下降。

这就是我这次演讲想讨论的问题：

AI Coding 进入组织之后，真正稀缺的不是“让 AI 多写代码”，而是让 AI 写出来的东西可以被组织稳定接住。

换句话说，业务代码日产万行不是靠“提示词更猛”撑起来的，而是靠一整套 Harness 工程底座托起来的。

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-3.jpg)

*组织困境：个人提效之后，组织交付不一定同步*

先说结果：这不是一个 Demo

过去两个月，我们的自研产品Kanban2 进入了一段非常高强度的建设期。

不是一个玩具项目，也不是一个局部试验，而是一个有前端、后端、CLI、测试、文档、Agent 运行时、环境脚本和交付流水线的百万行级工程。

按当时最新统计，三类代码已经到了 **175万行：**

- 业务代码约 88.8 万行
- 测试 + CLI 约 60.3 万行
- 文档约 26.2 万行

测试、CLI、文档并不是“附属物”，已经成为交付系统本身的一部分。

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-4.jpg)

*图 ： Kanban2 当前代码库规模*

*更重要的是增长速度。*

这两个月里，我们大概稳定增长了 **100万行级别** 的代码量。里面当然包括业务、测试、CLI、文档和 Harness 相关建设，但这恰好说明了一件事：AI 带来的高吞吐，不会只冲击业务代码，它会把整个工程系统一起推到极限。

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-5.jpg)

*图 ： 两个月稳定增长约 100 万行*

*如果没有一套能持续承接这种吞吐的 Harness，日产万行很快就会变成灾难：*

代码越多，越难验收； 提交越快，越容易返工； Agent 越多，环境越容易互相踩； 上下文越长，越容易丢失决策。

所以，这场分享表面上讲的是“日产万行业务代码”，底层讲的是：

当 AI 把个人生产力放大之后，组织要先补哪一段工程底盘。

**我理解的 Harness：**

**不是一个脚本，而是一套交付操作系统**

最近行业里也开始频繁讨论 Harness Engineering。

我自己的理解很朴素：Harness 不是一个测试脚本，也不是一个 Agent 框架，而是让 AI 能够在真实工程里稳定观察、行动、验证、恢复和协作的一整套运行底座。

它至少包含几类能力：

- 让 Agent 知道该读什么、按什么顺序行动
- 让 Agent 能造数据、跑测试、查日志、开环境
- 让 Agent 的修改有静态红线和动态闸门
- 让长程任务有计划、状态、证据和验收记录
- 让多 Agent 并行时不互相踩环境、踩端口、踩上下文
- 让人最终验收的是“结果包”，不是一堆解释

我们这次做的不是完整的 Harness 终局。

比如更高级的智能体编排、跨智能体工作流、长期记忆系统、Agent 自我优化、Meta-Harness，这些都还只是下一阶段方向。

但我们至少把一件事做实了：先让 Agent 不再裸奔。

这条路怎么修：

9 步 Harness 建设

我们最后把这条路整理成了 9 个步骤：CLI、数据、测试、观测、环境、验收、上下文、技能、优化。

它不是一开始设计得这么完整，而是在高强度交付里一段一段长出来的。

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-6.jpg)

*9 步路线图：先补 Harness，再谈 Agent*

第一步：先把 CLI 做成可编程验收机

很多人听到 CLI，会以为是给人敲命令的工具。

但我们做的 CLI，更准确地说，是一个“以命令行形态出现的可编程验收机”。它的主要用户不是人，而是 Agent、脚本和 fullcheck。

命令行只是最薄的一层皮，真正有价值的是背后的 setup、verify、session、fixture 和断言体系。

为什么要先做这个？

因为 Agent 写业务代码很快，但如果每次验收都靠人手点、手工造数据、人工看接口，那组织吞吐根本起不来。

所以第一步不是写更多功能，而是先把验收能力变成 Agent 可以调用的工具。

第二步： 利用CLI构造稳定测试数据

只有命令还不够。真实业务系统最大的问题之一，是“数据状态”。

一个看板、一张卡、一个字段、一个公式、一个权限、一个成员关系，都不是孤立的。很多功能必须在一个完整业务宇宙里才看得出来。

所以我们建设了 setup / verify 体系，让 CLI 可以从零种出测试组织，再围绕这个组织跑大量断言。

这一步的价值是：让 Agent 不再依赖人工造数。

没有它，验收会变成“你先帮我配个环境，我再看一下”；有了它，Agent 可以自己把现场搭起来。

第三步： 构建分层 fullcheck 闸门

CLI E2E 长出来之后，下一步不是“再写更多测试”，而是把它收进统一的 fullcheck。

fullcheck 最后变成 L0 到 L9 的分层闸门：

- 前面挡契约、编译、单测
- 中间挡组件级正确性
- 后面才碰真 Gateway、真运行时、真业务链路

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-7.jpg)

*fullcheck 实例：分层闸门如何定位失败*

这里有一个很重要的设计：L7 和 L8 不是重复。

L7 更像“一场景一组织”的 API 契约网，追求快、隔离、可并行。

L8 更像“一宇宙多 verify”的产品样板间，追求厚、可调试、可演示，还能接 UI 验收。

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-8.jpg)

*L7 与 L8：快而净的契约网，厚而活的产品宇宙*

这也是 Harness 和普通测试最大的差别：普通测试回答“这个函数绿不绿”； Harness 要回答“这个改动能不能进入交付系统”。

第四步：让 Agent 看得见环境

测试能告诉你“能不能合”，但出了问题以后，Agent 还要能自己看见现场。

所以我们补了可观测性：

- 本地 Loki + Alloy
- 共享 dev 环境日志查询脚本
- Agent 只读查日志
- 按 path / ERROR / ACCESS 反查 traceId
- 环境入口写进 docs / AGENTS / skills

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-9.jpg)

*可观测性：让 Agent 自己看见环境*

这块不要和 fullcheck 混在一起。

fullcheck 回答“能不能合” ； Loki 和环境契约负责“出了问题能不能自己查”。

以前是人去翻日志、问端口、猜 profile。后来变成 Agent 自己查日志、定位 traceId、确认环境入口。

这一步看起来不酷，但对长程 Agent 很关键。因为一个不能看见环境的Agent，只能不断问人。

## 第五步：**让 Agent 自己管环境，而不是等环境**

能查日志只是 “ 看得见 ” ，还不够。 Agent 改完代码之后，还要能自己把环境跑起来。

以前启停全栈是纯手工活：重启哪些服务、用什么 profile 、端口有没有被占，全靠人记、人猜、人盯。

我们把 “ 启停全栈 ” 写成了 Agent 可执行的契约：

- dev:restart:touched 读代码 diff ，只重启改到的服务，不搞全量重启
- agent:ui:open 预检 session / profile ， 缺 UI 时 自动拉起 preview
- check:services / detect:ui-profile 让环境状态可自证，不靠猜端口

这一步的收益在多 Agent 并行时最明显：每个 Agent 自己起、自己停、自己锁，不再互相踩环境。

再往后，管道和容器也进了 Harness 。

管道即代码： .cnb.yml 纯 YAML ，触发器、阶段、密钥 imports 都能进 PR 评审。

环境即容器： Nacos / MySQL / Redis / Kafka / ZGraph / Loki 都可以一键重建。

部署不靠人点： YAML 触发部署、重启、种测试组织， Dev 环境留给人验收。 AI 写完代码不用再 “ 等人点部署 ” ，才算真正端到端闭环。

改完后端自己重启，验收前端自己点亮——环境自治是多 Agent 不互相踩脚的前提。

第六步：让 Agent 能进 UI 现场验收

API 和 CLI 绿了， 不代表用户真的能点。所以我们又补了一层 UI 现场验收：

- Playwright MCP 控制真实浏览器
- feature map 告诉 Agent 功能在哪个页面
- agent:ui:open 负责免登录直达
- acceptance recipes 记录交互步骤和断言
- CNB 下关键改动还要求截图证据

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-10.jpg)

*UI 现场验收：功能地图 + 直达入口 + 浏览器操作*

这里的关键不是“页面能打开”。而是本次交付的能力，是否真的在 UI 上可见、可点、可验证。

我们不只给 AI 测试脚本，还给它一张功能地图和一把免登录直达钥匙。

## **第七步：给 Agent 完整文档上下文**

前面六步解决的是“ 改动做对了没有” 。但还有另一个问题： Agent 做的是不是该做的？下次换一个 Agent ，还能不能接着做？

所以第七步，是把上下文从聊天记录搬进文档文件系统。

我们的原则是：文档系统不是附录，而是 Agent 的只读内存。它分四块：

- 设计定真相： **docs/design** 承接需求、产品意图和 durable 设计， Agent 改行为前先对齐 SSOT
- 计划定节奏：大任务先拆成可执行计划，放进 **docs/plan/active** ，不散落临时目录；计划驱动落地，而不是即兴改
- 评审挡跑偏：计划评审和专题 review 进 **docs/review** ，把方向问题前置； CNB 下由计划 hook 负责关门
- 归档接得上：做完归档 **archived + state.md** ，当前事实沉到 state / quality / security / observability ，下个 Agent 能从同一状态继续

没有这套文档系统，上下文搬运只能靠聊天，换 Agent 就失忆。 代码可测试，决策也要可追溯；否则高吞吐会变成无文档乱写。

## **第八步：给 Agent 预装地图、技能和红线**

到这一步， CLI 、数据、闸门、观测、环境、验收都齐了，但还差一层： Agent 怎么知道这些东西的存在，又该按什么顺序用？

不能指望每次都在聊天里把背景重新讲一遍。我们把 “ 怎么用这个系统 ” 也工程化了：

- 文档是地图： **AGENTS.md** + **agent-entry-guide** 定阅读顺序， design / api / dev / testing / plan / review 分层承接知识
- Skills 是驱动：碰到 UI 、日志、 fullcheck 、 gateway 这些场景，直接按预装的 SOP 执行，少即兴发挥
- L1 是内核检查： 20+ 静态守卫在测试之前，先把违规代码拦住

这一步解决的是 “ 换 Agent 就失忆 ” 的问题。

经验如果只留在人脑和聊天记录里，每个新会话都要重新发明一遍流程；写成文档和 Skill 之后，流程是被预装的，换一个 Agent 也能接着干。

文档定入口，Skills 定流程，L1 定红线——先让 Agent 不迷路、不乱来，再谈日产万行。

## **第九步：持续优化，让 Harness 自己长厚**

九步不是一次修完就结束的路。 Harness 铺好之后，真正拉开差距的是日常优化。

我们的原则，是把每次失败反馈固化成可复用、可诊断、可强制的 fullcheck 能力：

- 正确性先收口： L1-L9 分段闸门把契约、编译、运行时分开挡，失败报告直接告诉 Agent 哪层挂了、怎么复跑
- 稳定性吃掉 flake ： **L8-retry** 、稳定性登记册、锁泄漏修复，让偶发失败可诊断，而不是 “ 再跑一遍试试 ”
- 降成本也要强制： path-aware 只跑受影响的分层，降低无效运行； CNB stop hook 让同一份 diff 必须过闸才能收尾

没有这一步， Harness 会停在脚手架阶段： flake 和慢反馈一直耗人，大家慢慢就不信了。

有了这一步，每一次失败都在给系统加一条护栏， Harness 才会产生复利。

反过来看：没有这些 Harness 会怎样？

没有 CLI，就只能手工验收。

没有数据底座，就只能手工造数。

没有 fullcheck，就只能靠人肉判断质量有没有回退。

没有 Loki 和环境契约，就只能到处拷贝日志、猜端口、猜 profile。

没有 UI 现场验收，就只能忍受“接口对了，页面不知道”的不确定性。

没有文档、Skills 和上下文体系，就只能反复把背景搬给下一个 Agent。

没有 stop hook 和强制闸门，就只能靠自觉。

所以 Harness 的价值，不是让流程变复杂，而是把原来那些不可见的人工成本，变成 Agent 可以执行、机器可以检查、人可以复核的工程资产。

使用心得1：

把流程也变成 Harness 的一部分

很多团队讲 AI Coding，只讲“怎么让模型写代码”。但真正落地以后，你会发现写代码只是中间一环。

我们的基本流程是：意图输入 → 低成本模型生成计划 → 强模型评审计划 → Agent 在开发机执行 → fullcheck / UI 验收 → 部署 Dev → 人工验收 → 单主干小步前进。

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-11.jpg)

*使用流程：意图、计划、评审、执行、验收*

这里有几个细节很重要。

第一，计划要落盘，不是聊完就散。计划进入 docs/plan/active，评审产物进入 review，做完再归档。

第二，执行机上要明确谁关门。CNB 模式下，Agent 回合结束前必须过 fullcheck，必要时还要补 UI 验收。

第三，人工验收前，Agent 应该交付“证物”：fullcheck 结果、关键截图、改动说明、计划链接、必要时还有日志线索。

这才是一个能进入组织流程的 AI 交付方式。

使用心得2：

重构不能欠，债务会被 AI 放大

这两个月还有一个很强的体感： AI 让你写代码更快，也会让技术债扩散更快。

如果计划评审时发现架构不对、边界不稳、命名不清、上下文不一致，不能因为“先跑起来”就放过去。

我们在高强度交付里做了大量 refactor，不是为了洁癖，而是为了让系统继续可被 Agent 理解、可被测试守护、可被人接管。

AI 时代对架构能力的要求不会下降，反而会上升，因为模型很擅长沿着已有结构继续生成。结构好，它会加速复利； 结构坏，它会加速腐烂。

怎么落地：

先别急着造智能体

我给团队的建议很简单：

先选一个中等复杂度的系统。太简单，看不出效果；太复杂，周期太长。

最好找一个 Pair：一个人懂业务系统，一个人架构设计能力强。如果一个人两者都强，那当然更好。

第一阶段，不要急着建专用智能体。先从零补一条端到端链路：

- 能造数据
- 能跑验收
- 能查日志
- 能启停环境
- 能定位 UI 页面
- 能把计划、评审和证据沉淀下来

先守护基本系统能力，再开始重构。等两个人都能人工达到比较高的交付吞吐，再考虑建设专用智能体和 Skill。因为很多智能体不是“建出来”的，而是“长出来”的。

很多企业现在的问题是：Harness 还没稳，就急着做 Loop Engineering、Graph Engineering、智能体编排。

这些方向当然先进，也一定会来。但如果人都不能稳定提效，却希望直接上一个能自动运行的智能体，大概率会变成空中楼阁。

我们还没做完什么？

最后需要说的是，我们现在做的只是 Harness 的一部分。

已经做得比较实的，是：

- 文档入口、Skills、L1 invariants
- CLI setup / verify
- 测试数据底座
- fullcheck 分层闸门
- Loki 可观测与环境契约
- UI 现场验收
- 多 profile 与启停自治
- CNB 强制闭环
- 基础设施 YAML 化、环境 Docker 化

但未来还有很多要补：

- 智能体编排
- 跨智能体工作流
- 长期记忆系统
- Agent 自我优化
- 任务轨迹沉淀与评估
- Harness 自身的持续演进

![文章配图](https://www.agilean.cn/cms-uploads/insight-65/image-12.jpg)

*后续演进方向：从工程底座走向自我优化*

这也是我对 Harness 的判断：它不是 AI Coding 的一个附属品，它会变成 AI 软件工程时代的基础设施。

结语

业务代码日产万行，听起来像一个产能故事。但我真正想分享的，不是AI 写得多快，而是组织怎么接得住。

如果没有 Harness，高吞吐只是更快地产生混乱。有了 Harness，AI 才有机会从个人工具，进入组织交付系统。

这条路不神秘。从一条端到端链路开始，把测试、数据、日志、环境、验收、文档和计划一点点补起来。先让 Agent 不迷路，不乱跑，不裸奔。然后再谈更高级的智能体编排和自我优化。

这大概就是我这两个月最大的体会： 先修公路，再上高速。

推荐阅读

- [RISE:适合复杂业务场景的版本迭代节奏](https://www.agilean.cn/insights-new/42/)
- [DEF 面向研发团队的绩效指标框架](https://www.agilean.cn/insights-new/43/)
- [精益研发效能提升框架 FLEET：提速增质的无限可能](https://www.agilean.cn/insights-new/44/)
- [DEER：研发效能提升路线图](https://www.agilean.cn/insights-new/45/)
- [ADAPT-中国金融企业规模化敏捷框架](https://www.agilean.cn/insights-new/46/)
- [聚焦研发效能度量5年时间，6点思考与沉淀](https://www.agilean.cn/insights-new/47/)
- [OKR的组织落地之旅：一步天堂，一步地狱](https://www.agilean.cn/insights-new/48/)
- [Agilean 2020年终巨献：数智化敏捷银行路线图](https://www.agilean.cn/insights-new/49/)
- [金融组织数字化研发管理的12种武器](https://www.agilean.cn/insights-new/50/)
- [数字时代组织效能的秘密](https://www.agilean.cn/insights-new/51/)
- [研发组织该如何设计绩效体系？](https://www.agilean.cn/insights-new/52/)
- [Google的软件工程概述](https://www.agilean.cn/insights-new/53/)
- [首发！第15份中文版全球敏捷状态报告来了](https://www.agilean.cn/insights-new/54/)
- [从0-1做产品快速启动，大型干货案例分享](https://www.agilean.cn/insights-new/55/)
- [你理解的精益可能是错的！——从源头重新解读精益](https://www.agilean.cn/insights-new/56/)
- [9个从零开始的B端产品自动化测试实践](https://www.agilean.cn/insights-new/57/)
- [金融组织做规模化敏捷怎么划小队，一文讲清](https://www.agilean.cn/insights-new/58/)
- [银行规模化敏捷速赢术第一式：部落制](https://www.agilean.cn/insights-new/59/)
- [从进化角度看规模化敏捷，上海银行4500+人实施案例——2023RSG大会演讲实录](https://www.agilean.cn/insights-new/60/)
- [软件国产化大潮下，这家金融企业是怎么替换Jira的](https://www.agilean.cn/insights-new/61/)
- [交付时效提升21%，宁波银行规模化敏捷试点这一年](https://www.agilean.cn/insights-new/62/)
- [上海银行｜用知微支撑全行2500人研发数字化管理转型](https://www.agilean.cn/insights-new/63/)
- [万字长文，细说长沙银行的数字化研发管理转型之路](https://www.agilean.cn/insights-new/64/)
- [AI强了，为什么组织还没变快？](https://www.agilean.cn/insights-new/66/)
- [当 AI 开始理解企业：金融复杂系统下的智能体实践](https://www.agilean.cn/insights-new/67/)
- [利用本体论和 EntClaw 构建软件开发生产线](https://www.agilean.cn/insights-new/68/)
- [别再拿“随缘发版”当版本火车了：跨越研发管理中“知道”与“做到”的生死线](https://www.agilean.cn/insights-new/69/)
- [从工作流到价值流：组织效能提升成不成，关键看这步 “转场”！](https://www.agilean.cn/insights-new/70/)
- [研发价值流：回退不是“后悔药”，警惕异常状态拖慢交付效率](https://www.agilean.cn/insights-new/71/)
- [AI时代的研发效能进化：从单点提效到组织重塑](https://www.agilean.cn/insights-new/72/)
- [对话吴穹：软件开发的终局，是我们将迎来自己的“黑灯工厂”](https://www.agilean.cn/insights-new/73/)
- [当CIO回答“我回去了解一下”的时候，科技就已经输了](https://www.agilean.cn/insights-new/74/)
- [研发的结构性拥堵，版本火车如何建立节奏与共识？](https://www.agilean.cn/insights-new/75/)
- [AI时代科技组织该怎么做？——先提质，再增效](https://www.agilean.cn/insights-new/76/)
- [最新预测：DeepSeek时代，科技组织即将发生的12大变化](https://www.agilean.cn/insights-new/77/)
- [破局研发管理困境：敏稳双态下的研发效能洞察](https://www.agilean.cn/insights-new/78/)
- [BizDevOps：从理念到实践，贯通企业全链路协同](https://www.agilean.cn/insights-new/79/)
- [解锁研发效能：平台工程的建设策略与实践](https://www.agilean.cn/insights-new/80/)
- [揭秘科技组织度量中心：构建透明、量化、高效的科技管理新体系](https://www.agilean.cn/insights-new/81/)
- [研发效能度量中心的底层逻辑](https://www.agilean.cn/insights-new/82/)
- [从测试本质看质量](https://www.agilean.cn/insights-new/83/)
- [管好研发团队四大要义](https://www.agilean.cn/insights-new/84/)
- [规模化敏捷下小队的协作机制](https://www.agilean.cn/insights-new/85/)
- [科技团队治理能力成长路线图](https://www.agilean.cn/insights-new/86/)
- [什么是引导？引导能为你带来什么？](https://www.agilean.cn/insights-new/87/)
- [提升代码质量：代码检查工具规模化使用实践](https://www.agilean.cn/insights-new/88/)
- [一窥科学管理：从误解到理解、再到构建](https://www.agilean.cn/insights-new/89/)
- [战略管理：质疑模型，理解模型，构建模型](https://www.agilean.cn/insights-new/90/)
- [6个原则+15项举措，重塑敏捷组织的绩效管理（下）](https://www.agilean.cn/insights-new/91/)
- [6个原则+15项措施，重塑敏捷组织的绩效管理（上）](https://www.agilean.cn/insights-new/92/)
- [合作模型与组织设计思考](https://www.agilean.cn/insights-new/93/)
- [渐进与激进的舞台，变革管理的艺术](https://www.agilean.cn/insights-new/94/)
- [管理变革思想，竟藏在运动康复之中？](https://www.agilean.cn/insights-new/95/)
- [看板方法：始于可视化，成于管理机制](https://www.agilean.cn/insights-new/96/)
- [数字化转型，组织架构先行](https://www.agilean.cn/insights-new/97/)
- [从推动到拉动：研发效能提升的第一性原理](https://www.agilean.cn/insights-new/98/)
- [3步，手把手教你用数据开好回顾会](https://www.agilean.cn/insights-new/99/)
- [一法则，一定理，数据驱动管理必备理念](https://www.agilean.cn/insights-new/100/)
- [魔幻的数字7±2 ——小队规模的底层逻辑](https://www.agilean.cn/insights-new/101/)
- [要管理，先可视](https://www.agilean.cn/insights-new/102/)
- [详述银行业数字化转型中的敏捷变革](https://www.agilean.cn/insights-new/103/)
- [数字化金融企业的产品体系长啥样？](https://www.agilean.cn/insights-new/104/)
- [研发效能度量的两大法宝、四大法门和七种武器](https://www.agilean.cn/insights-new/105/)
- [敏捷与规模兼得的高绩效组织打造](https://www.agilean.cn/insights-new/106/)
- [踩了那么多坑后，我们为什么还是要做目标管理？](https://www.agilean.cn/insights-new/107/)
- [从Cynefin框架重新理解不确定性管理](https://www.agilean.cn/insights-new/108/)
- [AI时代更需要敏捷组织](https://www.agilean.cn/insights-new/ai-era-agile-organization/)
- [WorkBuddy正当红，但Agent的未来不在聊天框](https://www.agilean.cn/insights-new/workbuddy-agent-future-not-chatbox/)

联系我们

发送邮件

联系方式

地址

深圳市南山区粤海街道南油社区建南路15号恒大天璟A座A2902

邮箱

contact@agilean.cn

---

来源：[日产万行业务代码背后，我们真正修的是一条 Harness 公路](https://www.agilean.cn/insights-new/65/)（更新于 2026-08-17）