“这是 AI 写的，我也不太懂。”

这句话相信大家在工作中最近都经常听到，无论是代码，还是ppt、文档，越来越多的人用Agent生成交付件。当你仔细追问其中一些细节（比如代码中某个配置文件中的几个参数到底是干什么用的）时，你就会听到这句话，让人有时也有一些无奈。

RTS游戏中，有一个经典的概念，”战争迷雾”，玩家只能看到自己及盟友单位附近的视野，但地图上的其他地方都无法看到，今天AI Agent开发的仓库，也存在着代码迷雾。

代码仍是最重要的交付件

一天完成一个library，三天完成PoC，七天完成一个产品初稿。我们不缺乏效率神话。

有些人把今天 Agent 写代码的变化，类比成从汇编语言到高级语言的跃迁：未来人只需要写自然语言、Prompt 或者 Spec，代码只是生成出来的中间产物。我觉得现在还不是这样，这两者之间还不存在类似高级语言到机器代码那样的完整映射。

当前代码仓里充斥着各类SDD的交付件，不止一个人问过我SDD生成的文件是否要合并到代码仓库，因为这些文档都像是生产环境中的缓存，代码才是那个Source of Truth。

除了代码之外，软件工程还不存在更高层次、同时又能与代码形成完整映射的交付件。也就是说：代码仍是最重要的交付件。

代码迷雾现象原本就存在，Agent只是加剧了这一现象

我喜欢另一个比喻：拖拉机和传统农具耕地，最终都完成了同一件事情——把土地耕好。但两者之间存在一种微妙的差异。

使用农具的时候，你几乎了解土地的每一道沟壑、每一次翻土的力度，你知道哪里坚硬，哪里松软，哪里需要调整。这个过程慢，但人与土地之间建立了直接连接。

而拖拉机极大提升了效率，它可以在更短时间内完成更多工作，但你未必了解每一寸土地发生了什么。你看到的是结果，却不一定理解过程中的细节，这和今天使用 Agent 写代码很像，这层看不见的部分，就是代码迷雾。

代码真实存在，也真实参与系统运行，但已经不在任何一个人的持续认知范围内。

这个现象并非由于有了Agent才存在，今天没有人能够理解整个 Linux 内核，没有人能够理解整个 Chromium，也没有人能够掌握一个大型企业系统的所有细节。Agent时代下，一个高速迭代的项目，会飞快地产生代码迷雾，随着代码规模不断增长，我们既没有能力，也没有必要把所有迷雾全部驱散。

代码迷雾时代，我们应该怎么做

现在如果你一定要手写每一行代码，那你一定会被人当做动物园里的猴子。

在 Agent 的帮助下，我们可以完成很多以前没能力、没时间，甚至不敢想的事情。这种感觉很好。这种感觉叫做无敌。

以前笔者可以算得上是经验丰富的开发者了，写过非常多的代码、组件，对一些仓库每个文件做什么了如指掌，最小化提交，优美的Commit记录。

但在 Agent 大幅提高代码生产效率以后，这种精细到代码颗粒度的维护方式开始出现效率瓶颈。如果仍然想着读懂、吃透每一行代码，很快人的理解速度就会成为整个开发过程的瓶颈。

对于个人来说，时间就是金钱，对于企业来说，如果不能充分提效，竞争对手就会充分地提效并超过你。

而且，以往团队的大颗粒PR提交，Committer真的认真看了吗？大部分时间大多数人都只是一个+1的机器。

所以我的第一个建议是：抓大放小，在合适的地方维护合适的颗粒度。

这并不是说以后我们只看架构、只看文档，不再看代码。

恰恰相反，我依然会在需要的时候进入某个模块，仔细读其中几十行代码，甚至单步调试，把一个问题彻底搞明白。区别只在于，我不再追求对整个 Codebase 都保持这种颗粒度的理解。

人的精力毕竟是有限的，关键是把精力放在哪里。

比如我让 Agent 帮我做一个后台系统，如果精力足够，我当然可以把每一个页面、每一个 Service、每一段实现都看一遍。但如果精力不够，我会优先维护几个我认为重要的东西：前端菜单、存储结构、API 接口。

菜单决定了这个系统对外呈现了哪些能力，存储结构决定了数据怎么组织，API 决定了模块之间如何交互。至于某个页面内部怎么实现、某个 Service 里面具体用了什么写法，我可以先允许它待在迷雾里面。

哪天这里出了问题，或者这一块开始变得重要，我再进去，把这一小片迷雾驱散。

所以颗粒度并不是只能向上，而是可以随时上下移动；关注的地方也不是固定的，而是取决于你认为当前什么东西最值得维护。

举个更具体的例子，这是我写在一个项目Agents.md里的一段提示词：

1

Implement features elegantly and with extensibility in mind. Split code into focused files/modules when that keeps the design clearer, reduces coupling, or makes future feature types easier to add.

我首先选择维护项目的定位、每个文件夹的作用，并要求 Agent 保持代码解耦，在合适的地方拆分为不同的文件、不同的模块。

代码维护不过来，那就重点维护代码结构。

代码结构也开始复杂，那就重点维护模块之间的关系、接口和文档。

文档越来越多，那就再建立文档的文档、目录的目录。

这不是放弃下面的细节，而是不再要求所有细节始终处于自己的视野之内。

我的第二个建议是不要追求局部完美，保证整体持续向上：

只要一个修改是必要的，并且经过了足够的验证，那就合并。没有必要因为其中几行代码自己没有完全理解，就让整个开发停下来。

今天 Agent 多写了一个模块，明天发现抽象得不好，那就重构；这次的设计不够好，下次继续调整。软件本来就是在一次次提交中逐渐演进出来的。

所以我不要求每一次提交都是完美的，也不要求每一行代码始终在人的视野里面。只要每一次修改是必要且经过验证的，整个 Codebase 的结构、边界和能力是在往上走，那就继续往前。

未来 Code 可能依然是最终最精确的交付件，但人未必需要始终工作在 Code 这个颗粒度上。

代码下面继续快速生长，人在更高的地方维护结构、边界和意图。需要的时候，再进入某一片代码，把那里的迷雾暂时驱散。

还记得小时候读过这样的一个故事：

有一个事业有成的老板，有空陪着母亲去逛超市，逛完超市之后，母亲提着东西，在公交站等车。超市的专属公交可以省两块钱的公交费。
公交迟迟没有来，老板不停地低头看表。
他想着”这几分钟，如果我投入工作，可能已经签下一笔订单、解决一个客户问题，甚至为公司创造了几十万的价值。”
但是他还是陪母亲等公交节约这两块钱。艰难时，母亲靠着勤劳与节俭，供他上学，将他养大；富足时，勤俭作为母亲的生活方式，依然能带给他满足与幸福。

近期我在负责AI辅助研发的工作，业余时间也会放大自己的思考，不禁在思考AI-Native 工作，AI-Native生活。

AI-Native工作很容易可以推导出来，要把自己在公司内的工作也转变为，Agent工作，人来决策、审核，对吧？

但AI-Native生活呢？怎么借助AI把自己变得又厉害又好？如果还是按照这个思路推导，人会变成一个毫无意义的审批节点。生活里很大一部分事情是为了享受，无论是 写文章、看电影抑或是与人斗，这些享受的部分、陪母亲坐公交的部分，你是不会委托给Agent的。

那我想现在的答案是”让人把自己不愿意做的事交给Agent”。人如何变得更厉害更好，那是另外一件事。在此之前，无论是通用Agent，还是编码Agent，大家的目标一定是 “允许人把人愿意委托的所有事情委托”。

现在已经是2026年7月份了，Agent辅助工作越来越普及，大家都在争先恐后地使用Agent提效。

但管理者真正焦虑的事情，似乎并没有变：团队到底有没有把 AI 用好？如果用好了，它真的带来了多少提效？这些提效，最后有没有变成可见的产出和业务结果？

这个问题看起来是在问”AI的效果怎么度量”，但本质上是在问”我们的研发效率该如何计算”？这个问题很难回答。

我们有很多AI来之前、AI来之后的过程指标，但这些指标都无法直接说明研发效率：

人均代码量

代码量这个东西作为指标，一直争议不断。一方面，大家都知道代码量不是越多越好，不同语言、不同模块、不同业务阶段，代码量都没有直接可比性。一个人写了几千行代码，不一定比另一个人改了几十行核心逻辑更有价值。

但是在Agent时代之前，代码量至少还隐含着一个很朴素的含义：它大概能说明一个人投入过时间。一年输出12万行代码的人，他几乎绝对是认认真真工作了一整年的。

但到了 Agent 时代，这层含义也开始变弱了。一个 Agent 任务跑十几分钟，可能就能修改几十个文件，生成几千行代码。一个开发人员一天产生的代码 Diff，可能超过过去一周甚至一个月。更麻烦的是，Agent 生成代码的边际成本很低。过去多写代码意味着更多人工投入，现在多生成代码可能只是多跑了几轮任务。生成出来的代码，开发者未必完整读过，未必充分理解，甚至可能只是靠编译、测试、运行结果做了一层确认。

过去代码量不一定代表价值，但至少可能代表投入；现在代码量既不代表价值，也不一定代表投入。

Token消耗量

很多企业会自然地统计 Token 消耗，这个数据最容易拿到，也最像”AI工作量”。

但Token本质上不是产出，而是成本。它说明企业为 AI 辅助研发投入了多少计算资源，但不能说明这些资源转化成了多少有效结果。

一个团队 Token 消耗很高，可能说明他们大量使用了 Agent。但也可能说明他们的任务拆分很差、上下文组织很差、代码结构很差、编译环境很差，导致 Agent 反复搜索、反复修改、反复失败、反复修复。这时候 Token 越多，不一定说明 AI 越有价值，反而可能说明整个研发系统对 AI 越不友好。尤其是Token的消耗量会随着解决问题的规模直线上升。

AI使用率

比如研发人员使用Agent的活跃度，它能说明 AI 是否真正进入了研发流程，也能够反映组织推广 AI 的进展。AI 使用率描述的是 工具的使用情况，而不是 工作的完成情况。

到这里，我们发现上面列举的指标，都有价值，但是都无法回答一个问题：企业到底有没有因为 AI 而真正提效？

企业从来不是为了让研发人员写更多代码，也不是为了让 Agent 消耗更多 Token，更不是为了提高 AI 使用率。企业真正关心的，其实始终只有一件事情：

能否用相同的资源创造更多价值，或者用更少的资源创造相同的价值。

同样的人，能否把产出提升X倍；或者产出不变，只需要1/X个人。

软件行业发展了几十年，一直没有一个所有人都认可的研发效率指标，可能最接近的是需求交付周期。

需求交付周期并不是研发最终创造的价值，它仍然只是一个过程指标。但相比代码量、Token、AI 使用率，它距离企业真正关心的结果已经更近了一步。一个需求交付得越快，意味着企业能够越快响应市场、越快验证产品、越快产生业务价值。它虽然不能直接代表企业收益，却已经开始影响企业收益。

但即便如此，需求交付周期仍然不能单独证明 AI 提效。需求交付周期只是结果，它并不会告诉我们，周期为什么变短了。可能是因为 AI，也可能是因为需求拆分得更细了，也可能是因为减少了测试环节，甚至可能只是因为统计口径发生了变化。

我们一直在寻找一个能够证明 AI 提效的指标，但在管理学中，对于这类复杂问题，通常不会试图寻找一个能够解释一切的”万能指标”，而是先建立价值创造的完整链路，再在每个环节选择合适的度量指标。

例如，一个团队 AI 使用率持续提升，Token 消耗持续增加，同时需求交付周期持续缩短，而线上质量没有明显下降，那么我们有理由认为，AI 正在开始产生价值。

反过来，如果 AI 使用率越来越高，Token 消耗越来越大，而需求交付周期没有变化，质量反而开始下降，那么这些指标也说明了一件事情：AI 被使用了，但并没有真正提效。

Logic Model（逻辑模型） 正是项目评估领域最经典的方法之一，它将价值创造拆分为 Input、Activity、Output、Outcome、Impact 五个层次，帮助回答一个核心问题：投入的资源，是如何一步步转化为最终业务价值的？

笔者尝试列举了一下，同时针对开发团队反馈的痛点问题，大家也可以按照这五个层次进行推演：

最后，对于 AI 辅助研发来说，没有一个万能指标。只有把覆盖 Input、Activity、Output、Outcome、Impact 的指标一起观察，才能尝试回答那个最初的问题：

AI，到底有没有让研发真正提效？

Flyway是什么

现代容器化交付模式下，当我们决定要发布的时候，从代码仓拉取分支，经过CI/CD构建，最终产出镜像包并发布。

但有些产品，数据库变更往往还是一个 SQL 文件、一段群消息，或者某个人手动在数据库里执行了一下。

Flyway 解决的就是这个问题：把数据库变更当成一种可以版本化、可追踪、可重复执行的工程交付件。它可以帮助开发者控制数据库的版本，并在应用程序中管理数据库的更改和迁移。Flyway的基本原理是跟踪数据库的更改历史，这样开发者就可以知道哪些更改已经被应用，哪些还没有。Flyway支持大多数的关系型数据库，如MySQL，PostgreSQL，SQL Server等。

Flyway主要针对Java语言，此外，也有一些Go、Python的移植版本。

Flyway原理

Flyway的运行机制可以抽象成如下几个流程：

迁移脚本的版本化定义

开发者通过约定命名定义数据库变更，例如：

1
2
3

V1_0__create_user_table.sql  
V2_0__add_index_to_user.sql  
V2_2__create_order_table.sql

SQL文件名遵循一个固定模式，版本号和描述之间用双下划线分割，版本号每个数字之间用下划线分割：

1

V<版本号>__<描述>.sql

数据库端的状态记录

Flyway在你的数据库中会生成一个叫做flyway_schema_history的表，用来记录数据库的版本迁移历史。

这个表的结构在Flyway的不同版本中可能有所不同，但是大致包含以下几个字段：

• installed_rank：这是一个递增的数字，表示迁移脚本的执行顺序。
• version：迁移脚本的版本号。这是根据你的脚本文件名确定的，比如文件名为V1__Create_table.sql的脚本，其版本就是1。
• description：迁移脚本的描述。这通常来自脚本的文件名，比如文件名为V1__Create_table.sql的脚本，其描述就是Create_table。
• type：迁移的类型。对于SQL迁移，这个值通常是SQL。
• script：迁移脚本的文件名。
• checksum：迁移脚本的校验和。Flyway用它来检测迁移脚本是否被修改过。
• installed_by：执行迁移的数据库用户。
• installed_on：迁移脚本的执行时间。
• execution_time：迁移脚本的执行时长（单位：毫秒）。
• success：迁移是否成功。如果迁移成功，这个值为True，否则为False

启动时的差量计算与执行

每次应用启动或执行 migrate 时，Flyway 会做一件事：

1. 扫描本地 migration 脚本
2. 读取数据库中 flyway_schema_history
3. 对比两者差异
4. 找出“未执行过的版本”
5. 按 version 顺序依次执行

执行完成后，将结果写入 history 表。

Flyway在团队内的实践

Flyway实践常见的问题

Flyway本身的机制是清晰的，但是在团队协作场景下，会有一些新的问题需要解决，例如：

研发过程中，一定会有一些错误，比如 某个字段，你开始的时候，觉得这个字段应该是个整数，但是后面他变成了字符串，那么在版本没发布之前，我们没有必要把研发过程中的错误，推敲的历史，也合并到最终版本中。这和我们强调，修复review意见，修改typo这些不要作为commit记录合并上来是一样的。Flyway最终服务的是生产环境，而不是开发、测试环境。

此外，还有一些SQL文件应该如何命名？SQL文件的粒度，是一个版本，还是一个特性，一张表？

SQL文件怎么拆

推荐在一个大团队内，所有微服务都使用一个合理的粒度拆分，这个粒度可以是 一个发布版本、一个发布版本里的特性等，选择一个合理的粒度拆分，我常用的是按照发布版本拆分，一个版本所有特性放到一个SQL文件里。SQL文件数量少，目录简洁，易于整理。

团队曾经在HCS场景下碰到一个问题，Flyway二十多个文件，中间偏偏有一个没有执行成功，最后也没找出原因 :(。尽量避免过多的Flyway文件。

Flyway团队协作机制

由上面的推导来说，无论是那种颗粒度，最终都会面临到开发过程中SQL文件的改动，这些老版本的SQL文件一旦上到测试环境上，我们就需要对环境做对应的清理，保障最终环境与生产的一致性。

在开发环境上，SQL文件修改，针对同名的SQL文件，Flyway会忽略不执行，开发人员要自行对表结构进行修复。

测试环境，一旦SQL文件发生修改，开发人员要对测试人员进行通知，并广播下测试环境进行改造的SQL语句。

开发过程中的版本，也就是非发布版本，不允许发布到现网，如果有现网POC项目使用非发布版本，也要做一定的清理，卸载后重装。

补丁版本原则上不允许修改表结构。

由于Flyway里面的SQL文件会有改动，需要留出一定的时间窗口（如版本发布前半个月不允许修改），以确保Flyway机制得到充分的验证。

上午重新整理了一下自己的数字资产，这篇文章跟大家分享一下我是如何管理我的数字资产的，这篇文章讲的方法可能也未必通用，也未必先进，希望大家能有所得。

我的数字资产管理方案是这么推导的，”我是谁？”->”我会产生哪些资产？”->”这些资产需要怎样的创作与管理能力？”->”我手里有哪些设备和存储服务？”->”资产存放与管理方案”。

数字资产管理的一些细节，跟你有什么设备、购买了什么软件、有什么云服务很相关，有时候会互相交织没有因果关系。

让我们接下来一步一步推导：

我是谁，会产生哪些资产？

按照数字资产的产生量和管理复杂度来看，我首先是一名软件工程师、开源爱好者，其次是家庭成员，同时周末的时候也会和家里人一起看看电影电视剧。

• 软件工程师、开源爱好者：大量与代码、文档、笔记、会议分享、论文、项目资料相关的资产。
• 家庭成员：家庭生活中的各种证件、体检、车辆等日常资料。
• 观影者：一些电影、电视剧、动漫等等。

这些资产需要怎样的创作与管理能力？

不同资产需要不同能力：

• 普通文件需要跨设备访问、目录组织、文件名搜索和全文检索。
• 代码需要版本控制、分支、提交历史和协作流程。
• 照片和个人视频需要时间线、人物、地点、相册和移动端浏览体验。
• 论文和书籍批注需要 iPad 阅读、手写、高亮和页面级上下文。
• 影视和大型媒体需要大容量存储和播放环境。

我手里有哪些设备和存储服务？

当前我有如下几个主要使用设备：MacBook Pro M1 Max、iPhone 15 Pro Max、iPad Pro M5。

之前我还有一个 Windows 台式机，后面因太占地方已经二手出掉了。

除了这些设备外，我还有以下几个存储订阅/设备：

• Microsoft 365 订阅：自带 1TB OneDrive 空间，适合多平台访问，多平台支持良好。
• iCloud（家庭共享）：每月 21 元，提供 200GB 空间，与 Apple 系生态深度融合。
• 家用 NAS：群晖四盘 NAS，目前插入了一个 16TB 的硬盘。

资产存放与管理方案

如果你看中你的资产，照片、PPT，或者是代码，一定要做好容灾。比如放在家中 NAS 里，不管多少个盘都有同一个故障因子，这时候可以叠加一个远程备份，比如到 OneDrive、百度网盘之类。

商业公司里较高的标准就是3-2-1 原则：

• 3：存储 3 份完整文件，一份原件加上两份拷贝。
• 2：将文件起码保持在两种不同的介质上。
• 1：将一份拷贝保存在异地。

我自己也没按 3-2-1 原则搞的那么复杂，觉得丢失也无所谓的东西就放在 NAS 或者某个设备的硬盘上，有所谓的东西就放在 OneDrive、iCloud 或者 GitHub 上。

我的资产存放原则是：优先使用云盘和开放格式管理文件型资产；对于照片、批注、手写、影音等专业场景，则交给更合适的 App 或设备。低心智快速存放，灵活搜索即可，不追求一次性精确归类。

更适合交给专业系统管理的资产如下：

• 代码资产使用 GitHub、GitCode 等进行管理。
• 论文、书籍的阅读批注版放在 Goodnotes。
• 当前正在手写的草稿放到 Notability。
• 个人照片、短视频使用 iCloud 照片管理。
• 影音（并非个人特殊），承载不属于个人独占的数据（如电影、公共资料等）使用 NAS 进行管理。

我尝试过多次，要不要在 Notability、Goodnotes 两个软件之间归一，最终都以失败告终。

Goodnotes 没办法快速进入手写，Notability 进入空白笔记只需要一次操作，Goodnotes 要两三个操作，功能、概念太多导致的复杂性，有利也有弊。

Notability 之前不支持多级文件夹，现在好像是支持，但是仍不支持不同文件夹下笔记重名，两者的数据存储模式，似乎一个是文件夹方案，另一个是平铺再加标签方案。这导致一些很结构组织化的管理用起来不舒服。

排除掉这些更适合交给专业系统的资产后，剩下大量 PPT、Word、PDF、Markdown、图片素材、参考资料和博客内容，我都把它们放在 OneDrive 中，OneDrive 是我个人文件型数字资产的核心仓库。

为什么是 OneDrive

我个人同时订阅了 iCloud 和 OneDrive，选择 OneDrive 的核心原因主要是：iCloud 云盘与 macOS 的文件删除行为联系紧密，清空 Mac 回收站同时彻底删除 iCloud 中的文件。相比之下，OneDrive 上存在一个网页回收站，我曾经失误将 OneDrive 挂到 Linux 目录上 rm -rf 过，最终还能找回。

OneDrive：文件型数字资产的核心仓库

在 OneDrive 中，我按照以下原则来组织：

1. 以 OneDrive 为中心，App 只读

以 OneDrive 为中心，App 只作为阅读器/浏览器，随时访问文件、打开、批注，可以像 PowerPoint 一样缓存 OneDrive 里的文件，但不要把文件导入到自己的沙盒里（比如 Readdle 那种要复制一份进 App 内部的），不产生多份拷贝。

2. 跨平台访问，开放格式

跨设备/平台可访问，使用开放的文件格式：

• 拒绝非标准封装或 App 独占格式（如 Evernote ENEX、Notion 数据库导出）。
• 文件就是资产本体，不依赖数据库或工具才能访问。

3. 低心智快速存放，灵活搜索

现如今的搜索功能都非常强大，我们并不是在维护一个图书馆。如何让一个文件/资料更低心智地存放、更低成本地找到，往往比如何把它分类得绝对正确更重要。

很多人在整理文件时容易陷入一个误区：希望设计一套完美的目录结构，让任何文件都能找到唯一且正确的位置。但现实情况是，一个文件往往同时属于多个维度。

比如一篇关于 AI Agent 的 PPT：

• 它可能属于某个项目；
• 也可能属于个人技术研究；
• 还可能是一次会议分享材料；
• 未来甚至会成为参考资料。

如果为了追求分类准确而不断调整目录，最终维护成本会远远超过收益。

4. 整体参考 PARA，但不原教旨使用

Projects 用于阶段性推进，Areas 用于长期领域积累，Resources 用于参考和复用，Archive 用于保存已经结束的内容。

我没有在 OneDrive 下面再创建一个“个人资料库”之类的目录，而是直接使用根路径。这样做主要是为了降低访问成本：在 Finder、手机 App 上，这些核心目录都能少一跳访问。

同时，我将对外的 Blog 和家庭档案保留了独立的目录（小规模，高度内聚按 Topic 聚合）。

在微软生态下，OneDrive 的根路径很容易就会有文件夹 Documents（还有 Attachments，只要你用了 OneNote、Outlook 这样的软件），刚好把 LiteratureNotes（文献笔记）、ReadingNotes（读书笔记）放到 Documents 中。

在 PARA 方法论中，还推荐使用 Inbox 路径，用于接收和暂存尚未完成分类或后续仍需处理的信息与文件。Inbox 作为整个系统的缓冲区，帮助用户快速捕获外部输入，避免在信息进入系统时频繁进行分类决策。对于归属明确的内容，也可以直接存放到对应的 Projects、Areas、Resources 或 Archive 中，而无需经过 Inbox。

我这里稍微有点特殊，个人场景里的外部文件流没有公司里那么密集，反而是零散想法更多一些，很适合放到 Documents/FleetingNotes（闪念笔记）目录里，再搭配上操作系统自带的下载路径（这类文件应该被快速迁移，同步到云盘价值也不大），临时手写草稿则先放在 Notability 里。这样一来，我就没有创建 Inbox 路径，也可以说是把 Inbox 路径给分解了。

如果换一个场景，比如公司内，经常有各种材料从 IM、邮件等涌来，我想我一定会创建一个 Inbox 文件夹。这个场景下，Inbox 已经承担了临时入口的职责，就不一定需要 FleetingNotes 目录。LiteratureNotes、ReadingNotes 如果有 Documents 这样的顺手目录就继续放，没有的话也可以移动到 Resources 下面。

5. 如无必要，不新增文件夹

目录不是越细越好。目录越细，判断成本越高（有些文件就没有合适的单一维度可用于 MECE 分类）。这就像代码要不要分目录、分包一样，有点多了的时候再分包即可。

6. Resources 按资源类型组织，避免变成”垃圾桶”

Resources 如果文件夹建得不好，最容易变成“资料”垃圾桶，所以我给它加了一个限制：

一级目录原则上按资源类型组织，而不是按临时主题、来源或场景来建。如 Images、Videos、Slides、Docs、Sheets、Books、Papers、Standards（标准）、Templates、Prompts、Skills 等这些资源类型。

如果一级目录下，该类型的文件非常多，可以继续创建下一层目录，但二级目录也应该尽量使用稳定、客观的分类维度。比如 Templates/PPT、Tools/Macos、Standards/RFC、Pcap/MySQL 这类目录就比较稳定，尽量避免用“学习”、“AI”、“重要”这类名词，它们刚开始看起来很顺手，但时间一长，边界会越来越模糊，最后又变成一个新的“垃圾桶”。

少量天然跨格式、经常按资料包整体检索的集合可以作为一级特例。目前只有 Conferences，一个会议资料包里可能同时有 PPT、PDF、图片、视频、讲者指南和模板，如果强行拆散，反而不利于查找。会议资料如果已经拆散并按类型使用，也可以放入 Resources/Slides、Resources/Images。

Templates 虽然也可能包含 PPT、Word、Excel 等多种格式，但它的共同使用方式非常明确：作为模板被复制和复用。因此我把它作为 Resources 下的稳定资源类型，而不是特例。

最终 OneDrive 的顶层目录如下：

• 家庭：家庭长期档案库，保存体检报告、工作合同、医疗记录、考试成绩单等资料，不使用 PARA 拆分。
• Archive：存档目录，已完成或不再关注的 Areas、Projects、Resources 归档。
• Areas：领域目录，保存需要长期维护的责任领域、主题积累和个人成果。内容通常会被持续补充、更新和复用。
• Attachments：附件目录，由应用统一管理，不承担个人文件的主要分类职责。
• Blog：博客目录，保存面向公开发布的文章及其配套图片。
• Documents：个人笔记和文稿目录，保存读书笔记、文献笔记、闪念笔记，以及尚未依附于具体项目、领域或发布目标的普通个人文稿。
• Projects：项目目录，保存正在推进、有明确目标或结束条件的事项。
• Resources：资源目录，保存可查阅、可复用、可调用的资源资产。Resources 中的内容可以编辑，但主要用于查阅、调用、复制、复用或支持其他工作。通常以别人或组织产出的资料为主；自己产出的内容如果已经从“一次表达”变成“通用素材、模板、案例、培训材料或可复用组件”，也可以放入 Resources。

对于一个文件，按如下链条判断位置：

• 是否属于家庭成员、共同资产、家庭财务或生活档案？→ 家庭
• 是否明确服务当前项目交付，并且项目有目标或结束条件？→ Projects
• 是否面向公开发布，例如博客文章及其配套图片？→ Blog
• 是否属于长期责任、长期能力沉淀，或自己的研究过程？→ Areas
• 是否是自己正在写、整理、发展，但尚未归属项目、领域或发布目标的文稿？→ Documents
• 是否主要用于查阅、调用、复制、复用，或者来自会议、外部资料包？→ Resources
• 是否已经结束、废弃、低频但仍需要保留？→ Archive

专业 App：只承担特定场景

Notability 我只写一些临时草稿，写好了就会整理到 OneDrive 去，基本没什么管理，常年不会超过 10 个笔记。
Goodnotes 我只管理批注版书籍和论文，因此目录很简单。

• Books：存放批注的书籍。
• Papers：存放批注的论文。

结尾

这套方案并不是一次性设计出来的，而是在我的工作内容、家庭资料、设备条件、软件订阅和历史使用习惯之间慢慢折中出来的。数字资产管理不应该追求一种抽象上的完美分类，而应该降低日常使用时的判断成本。在搜索能力愈发强大的当下，快速整理存放，把时间放在产出而非整理上更重要。

TL;DR

AI辅助研发已经走过Chat、Copilot，进入Agent时代，为了让Agent更大程度地帮助人们提效，AI生成的产物，要直接成为研发流程中的交付件，并且要易于编辑审核。SDD将海量，人难以review的代码抽象成了更易编辑审核的SPEC，但目前业内大多数 SDD 实践，还主要停留在“代码生成”阶段。而在真实企业研发中，代码只占整个研发活动的一小部分。漏洞处理、现网事件、上线说明、影响评估…….未来整个流程逐渐演化为Agent输出可结构化、可审核的交付件，人仅审核的方向发展，最终”SDD会吞噬一切”。

为什么会有SDD，SDD是什么？

现在是2026年，距离GPT4发布已经过去了3年，AI辅助研发，经历了很大的改变，从Chat、Copilot再到Agent。现在没有用过Agent模式辅助开发的人，恐怕你已经有一些落后了。

Agent模式下，AI生成代码的速度越来越快，以原先的方式提交、检视代码，甚至合并冲突都非常耗时，这种模式下，人越来越没有能力掌控代码。

这是我在开发一个提效助手项目时跟Codex对话过的原话：

我在“如何让AI真正替你干活“中提到过提效的关键取决于”AI生成的产物，是否是最终的交付件，是否易于编辑。 代码本身是易于编辑的，所以它成为了AI率先提效的对象，但量变引起质变，海量的代码已经不再易于编辑和审核。

为此，人们在已有的软件工程下，追求新的抽象层次，代码不好维护，那我想办法维护别的不就好了？

这就是SDD的核心理念，SDD通过结构化的规格文档（Spec）作为可信生成源，让 AI 围绕规格进行实现，而人类主要审核规格本身，而不是陷入海量代码细节。这些规格通常以 Markdown 等易读、易维护的形式存在，例如 Spec.md、design.md、tasks.md 等。

这就好像，我生成一个短剧视频，比如一次生成了2min，我想修改里面的部分很难，但是如果我先用AI生成首尾帧图，每次生成5秒钟，我先调整首尾帧图，再生成一样。

不过从目前的实践来看，SDD还没能那么理想地屏蔽掉代码层，一些小修改，例如配置、端口、脚本、热修复，我们仍然会直接修改代码文件，而不会重新回到 Spec。

但无论如何，SDD已经算是目前较为优秀的一种实践。这同时也让我们理解了要让AI生成的产物，就是最终的交付件，要易于编辑。

企业级研发全流程提效的下一个阶段

目前业内主流的SDD的实践，比如OpenSpec，主要聚焦于代码生成流程：

但是在企业级研发中，真实的研发活动是一个由大量角色、流程、交付件组成的网状协同系统，单纯的写代码，只占真实研发活动中的很小一部分，比如还有 友商的洞察、漏洞检测报告漏洞处理。

那么这些步骤，其实像OpenSpec这样的工具还是帮不上忙的，我们举几个例子：

场景一：漏洞报告处理

企业今天可以通过扫描平台、运行时检测等工具，自动发现大量漏洞。但真正耗时的，其实并不是修改漏洞代码本身，而是整个处理流程：

代码修改只是其中的很小一个部分，还有很多阶段还没有让Agent介入，可能还只是在用”Chat”模式提效。接下来通过开发Agent，由Agent分析漏洞影响输出交付件，人确认，Agent基于漏洞处理的特点（修改尽量不要太大等等）给出修改意见，人确认，自然而然地达成全流程AI提效。

场景二：SDD、TDD融合

Agent把个人的能力放的这么大，我有时也跟朋友闲聊到，将来一个小的公司，老板不太懂的情况下，三个技术人员就够了，又有容灾能力，又能讨论决策出结果。

然而大企业却绝不可能只招聘数个技术人员，这就意味着没法尽量让一个人负责工作的各个方面，有些研发流程就很适合像”首尾帧”那样拆解。

过去很多团队推行 TDD（Test-Driven Development），开发人员不是先写代码，而是先写 测试用例、输入输出，然后再让代码去满足这些约束。

有些很极端的例子，比如
func sum(x, y) {
return 42;
}
先让40+2的用例通过。

某种程度上来说，TDD其实已经具备了一部分 SDD 的思想 不再直接围绕代码本身开发，而是围绕“可验证的约束”进行开发。 但是在过去这个成本非常高。现在充分利用Agent的能力，我们甚至可以做得比Agent直接生成代码更快更稳。

最终，这个流程的每一个红色箭头，都可以使用Agent快速提交，并且每一步都有可审核、可编辑的交付件，希望不会再出现文章开头的问题(笑)。

总结

我们在这里还只展开了两个流程，真正企业里的研发流程只会更加复杂，我让AI生成了一张图：

最终，随着Agent产出效率越来越高，整个研发流程都需要尽量使用Agent提效，这些原本依赖大量人力协同的研发交付流程，最终都会演化为”Agent生成交付件，人类负责最终审核与治理”。而整个企业研发体系，都会围绕这些交付件重新组织，最终SDD会吞噬一切。

我写这篇文章来抒发一些想法，另一方面是作为我之前一篇文章的后续。此刻，我又想起来聂帅给我讲过的”人的思维是螺旋上升的”。

我们还是以开发者测试举例，因为之前提了很多想法，虽然我的角色有些变化，大家还是在找我讨论，谢谢大家看得起我（笑）。

为了满足读者的背景，我来给大家快速补齐一下角色和平台：

• 测试：把握整体，确保测试的分层，避免大量都是耗时的集成测试用例，结合我们的资源、我们的开发测试比例，将部分确定性，执行相对更简单的测试放到开发者侧。
• 开发：按照测试的总体设计书写用例，这有很多种方式，比如就写在代码的test里、用低码平台书写，但核心你一定要和测试平台关联，这个关联有很多方式，低码平台那自然是天生关联的，写在本地代码里的话呢？有很多方式，我最推荐的是用测试平台的id（这可能有意义，也可能无意义），Anyway，再把测试平台的描述（这很让人难看懂）放到测试方法的注释里。这样我们测试就只有一个Truth，就是测试平台，从工程上会更好。当前为了炫技，我还考虑过用Powershell解析Java语法生成，还买了一本Powershell的书（笑），需要投入太大，后来就没搞了。
  
• 某低码平台：没什么的好说的
• Test平台：基本上上面都讲了

2024年，我倾向于在代码仓书写测试用例的方式来完成API Test的工作，它实际会更快一点。
2025年到不久之前，我在想低码化是不是更好，代码将来是burden，是负担。人来仅维护描述，测试用例的书写相对很模块化。

但是，最近我们将 测试平台的id（这可能有意义，也可能无意义），Anyway，再把测试平台的描述（这很让人难看懂）放到测试方法的注释里 这一部分SKILL化了，这是很大的提升，过去，我们对着测试平台一个一个复制方法名称，再把描述拷贝到注释里，这样的工作不复存在了。SKILL起码把这一细分流程的效率提升了10倍以上。可以预想，开发者不会再抗拒这个工作，为什么要拒绝有丰富经验的测试帮你设计好的用例呢，同时还生成了方法名、注释来引导Agent更好地生成代码。

这某种程度上也是贯彻SDD的理念，将流程串起来了。

最后是我想抒发的感受，过去，我们开发一个这样的工具，可能需要一周以上的时间不止，现在我们用SKILL，优秀的工程师们，一天乃至半天的时间就可以完成。尝试让AI Agent直接生成交付件，把重复的工作SKILL化。

AI已经极大程度地更改、影响了这个世界的走向，我们可以看到一些趋势，比如 画师、网文写手、真人短剧逐渐地被替代，程序员的替代还没有那么快。

大家有没有想过这个原因呢？我认为核心就在于：AI生成的产物，是否是最终的交付件。

这和Leader分配任务给下属一样，如果下属的交付件可以直接用，那Leader可能就说，你这个代码日志一定要符合规范、你这个材料字号要调大一些；反之，可能Leader就用下属的没那么完美的交付件，自己再整理成最终的交付件。

而程序员的情况不同：代码不是最终交付件，系统才是。

代码只是中间产物，它需要：运行、集成、部署、监控、演进。这一整条链路还没有完全“标准化交付”，所以替代速度较慢。

那么结论其实很自然，个人提效的关键就在：让AI Agent直接生成交付件，这个交付件一定要是可通过迭代提示词、上下文不断优化的，最好这个产物是可编辑的（Markdown、Excel、Html），最后一公里的时候人可以做一定的修改。我在2月27日的朋友圈里也表达了类似的观点。

那么怎么更好地让AI Agent生成工作中用的交付件呢，我目前的实践是 Agent+MCP+SKILLS+PARA。Agent 负责执行，MCP 连接外部世界，SKILLS 提供可复用能力，PARA 提供稳定上下文，我们一个一个解释。

Agent+MCP

Agent毋庸多说，相比于只能对话的LLM，是一个围绕目标，能够多步执行、调用工具并持续迭代的执行单元。Ask模式（只跟AI对话）是没法更进一步地提效的。

SKILLS

SKILLS可以理解为一组可复用的能力模板（Prompt + Tool + Workflow 的组合）。例如

• 整理Inbox文件
• 生成周报
• 分析某个Area的内容
• 输出某种固定格式的文档
  如果没有SKILLS，每一次都在“重新提示AI”，有了SKILLS，相当于把最佳实践固化下来，交给Agent反复使用。

PARA

对于Agent来说，与其给 AI 造新工具，不如给它一个它已经「会用」的旧接口。在于 LLM 的训练数据。LLM在训练阶段已经看过了很多文件系统的操作，grep、ls、find等等。LLM会非常善于在文件系统里探索他想用的内容，而不是拼凑一个高度定义的DSL。

PARA呢，和文件系统强强联合，给Agent提供了一个稳定、可理解的上下文环境。

个人实践案例

我的PARA目录

PARA是一个指导原则，每个人的PARA都可以有一些定义，比如我的PARA目录是这样子的，适配了我平时使用的OneDrive(它会强制有一些顶层文件夹，我自认为巧妙地利用起来了)，同时我还有把一些作为Blogs发布的诉求。同时也放了一些README.md、About.md 方便Agent读取。

如果大家感兴趣的话，我可以单独写一个文章介绍一下。

1
2
3
4
5
6
7
8
9
10
11

生活/
Archive/
Areas/
Images/
Blog/
Documents/
Projects/
Resources/
Software/
About.md
README.md

下面的实践过程，本质上不是一次性的。

如果你每隔一段时间都需要做类似的事情，比如：

• 盘点近期工作成果
• 挑选可以对外分享的主题
• 判断哪些材料已经足够支撑一次输出

那么这个流程其实是高度稳定的：

1. 扫描目录
2. 识别活跃内容
3. 提取关键材料
4. 组织成候选结果

这类流程，就可以被固化为一个 SKILL，例如

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Skill: summarize-workspace-for-sharing

输入：
- 一个工作目录路径

输出：
- 可用于分享的主题列表
- 每个主题对应的支撑材料
- 是否已经具备“可交付”的判断

内部流程：
- 扫描最近活跃文件
- 聚类主题
- 评估材料完整度

这样一来，下次再做同样的事情，就不需要重新写 Prompt，而是直接调用这个 Skill。

实践1：筛选个人成果用于会议分享

向 Agent 提问

1

这是我的个人工作文件夹，你可以看看我最近几个月的工作成果，看看有没有什么东西可以拿去"ApacheCon"分享的？

Agent 回复

1
2
3
4
5

我会先快速梳理这个工作区最近几个月的文件分布和活跃项目，找出适合做 ApacheCon 分享的候选主题，再回头看哪些材料已经足够支撑成一场 talk。

已探索 3 个列表，ran 1 command

我已经看到这个目录更像一个长期知识库，不只是单一项目，所以接下来我会缩小范围：重点看近 6 个月新增或活跃的 Apache / 开源 / AI研发 相关材料。

实践2：整理 Inbox，迁移到合适的 PARA 目录

个人文件夹里最容易失控的地方，通常不是 Projects，也不是 Resources，而是各种临时下载、微信传文件、会议附件、截图和草稿。它们会先堆在一个“待处理区域”里，时间久了以后，人自己都不太愿意翻。

这种场景其实很适合交给 Agent。因为它不需要一开始就“理解整个世界”，只需要先做一件很具体的事情：识别这些文件分别属于什么类型，应该进入哪个目录。

向 Agent 提问

1

这是我的 Inbox 目录，里面有很多最近积累的文件。你可以帮我分析一下这些文件分别属于 Projects、Areas、Resources 还是 Archive 吗？先不要直接移动，先给我一个整理建议和理由。

Agent 回复

1
2
3
4
5

我会先扫描 Inbox 里的文件名、扩展名、最近修改时间，以及部分文档内容，判断这些文件更像是项目资料、长期领域资料、通用参考资料，还是已经可以归档的历史内容。  
  
已探索 4 个目录，ran 2 commands  
  
初步看下来，这里面混合了会议纪要、下载的安装包、临时截图、正在推进项目的材料和几份标准文档。我接下来会先按“是否仍在活跃使用”进行第一轮分类，再给出建议路径和批量整理方案。

实践3：让 Agent 总结一个 Area 当前都积累了什么

有些 Area 是长期负责的，比如英语、软件工程、孩子教育、投资理财。这类目录的问题不在于“没有内容”，而在于内容太多了，久而久之自己都不知道里面已经沉淀了什么。

Agent 很适合做这种“盘点当前资产”的工作。它不一定直接帮你产出最终文档，但可以先把目录里的内容做一轮结构化总结，帮你建立重新利用这些内容的入口。

向 Agent 提问

1

这是我 Areas/软件设计 目录。你可以帮我看看这里现在主要沉淀了哪些内容？按主题帮我归一下类，再告诉我哪些内容已经比较完整，哪些内容还只是零散积累。

Agent 回复

1
2
3
4
5

我会先浏览这个目录下的子目录和关键文档，判断当前沉淀更偏向方法论、实践记录、工具使用，还是项目复盘，并整理出一个主题结构。  
  
已探索 5 个目录，ran 3 commands  
  
从目前看到的内容来看，这个 Area 里既有一些长期积累的方法论笔记，也有若干和具体项目相关但仍有复用价值的实践文档。我接下来会把它们拆成几个主题，并标出哪些已经可以整理成对外输出的文章或分享材料。

实践4：从一个目录里提炼周报 / 月报素材

很多人写周报、月报最痛苦的地方，不是“不会写”，而是回头找素材太费劲。尤其是当你的工作记录分散在会议纪要、草稿、截图、PRD、临时文档、代码仓库说明里时，人会本能地拖延这件事。

如果文件组织本身还算规整，Agent 就可以直接从目录里提炼候选素材，最后输出一个可编辑的 Markdown 初稿。

向 Agent 提问

1

这是我最近两周的工作目录。你可以帮我整理一版周报素材吗？先按“已完成事项、推进中的事项、问题和风险、下周计划”四个部分来归纳，尽量基于已有文件内容，不要凭空发挥。

Agent 回复

1
2
3
4
5

我会先查看最近两周活跃修改的文档和项目目录，提取其中能够反映工作进展的内容，再按周报结构组织成一版可编辑草稿。  
  
已探索 6 个目录，ran 3 commands  
  
目前已经看到几个高频修改的项目目录，以及两份会议纪要和一批方案文档。我接下来会优先提取能够代表实际推进结果的内容，避免把讨论中的想法误写成已完成事项。

参考资料

1. Agent：一切皆文件：https://mp.weixin.qq.com/s/ulmVG3_yrfy-7EofRgnyGw

其实，一直写Java，用Spring框架的同事，一定会觉得依赖注入就像呼吸一样。但是在其他语言的开发者看来却不尽言。

我在项目的开发过程中使用过Java，也使用过Go语言。见过很多写Go语言的同事对Spring框架嗤之以鼻。也被同事讲过写的代码Java味很重，emmm，学习一个语言就要学习它的最佳范式与哲学，这我无比地认同。

首先，依赖注入 != 依赖注入框架 ，比如

1
2
3
4
5

type Client struct {
  logger *slog.logger
}

client.logger = newLogger()

其实，这样显式地为 logger 赋值，本身就是一种依赖注入。 只不过，它是手动注入，而非通过框架自动完成。

如果完全不用设置，那就代表这个模块是单例的，举个例子，Java中的log4j2，绝大部分场景下都是单例的，通过配置文件来反向控制某个包下面的日志级别等等。

之前读过一本书有个很有意思的理念，就是”包变量/静态变量”是不好的，是违反物理规律的。

只是由于种种原因，在程序运行时，只存在一个实例。25年1月份，在一个Go项目中，我做的一件重构就是把原本的包变量引用替换成了成员变量，因为发现在运行中会存在多个相应的struct实例，他们对这个变量的需求是不一样的。

那么依赖注入框架呢？
其实Go语言也有很多依赖注入框架，如果有很多的strcut都要get、set，那建议还是使用依赖注入框架。我做的项目没有使用依赖注入框架，主要有两点原因

1. Go语言依赖注入没有形成统一的标准。
2. 其次，目前产品还没有很多的strcut都要get、set。

DI框架本身也有学习成本，这块框架我没有详细了解，如果能在工程组织，测试上大大简化的话，我还是很乐意用的

一方面，是Vibe效率的飞升：三天完成一个Demo，一下午Vibe一个Poc项目。
另一方面，是企业效率没有想象中的提升，似乎，没有AI辅助流程，对企业没有任何影响。

为什么？

首先，这是极具代表性的两个开发场景：
其一，单人开发，担任产品经理、开发、测试、运维角色，一人承担所有的责任。（即使GPT写错了付款接口你也只能责怪自己）。
其二，多人协作开发，分工明确，各自承担不同的角色与责任。

基于此，针对AI辅助开发，笔者分析整理了三个原因，这三个问题层层叠加，从模型能力到系统隔离，再到协作方式，构成了企业级 AI 提效的现实瓶颈。

一、模型、算力

模型的推理能力、支持上下文的长度，对工具的效果影响是天差地别的。企业出于对资产安全的考虑，往往会选择私有化搭建模型，这可能会导致如下两个问题：

• 内部模型参数量较小：推理能力明显低于公有云大模型，尤其在多语言代码生成和复杂语义补全上差距明显。
• 上下文长度受限： 受限于上下文窗口，AI 工具只能看到当前编辑文件或部分上下文，导致生成结果割裂。

  先进的理论、经验都是基于AK 47的，确定一定要基于AK 36继续优化么？

二、信息系统孤岛

在传统的逻辑下，将信息分隔到多个系统，进行精细化管理，通过人来串起整个流程，这无疑是非常优秀的做法。笔者也曾经将团队中的所有数据库相关实体定义集中到一个代码库管理。

而AI辅助开发工具通常运行在代码仓，单人开发模式下，我可以把设计文档提交到代码仓，典型测试集都提交到代码仓，编写代码需要的Everything，只要适合转换为文本模式的，我都可以提交到代码仓。

在AI辅助开发工具没有集成对应信息系统的情况下，需要开发人员手动提炼复制上下文到AI辅助开发工具，这和我再提炼提炼，以Chat的方式对话，有什么区别？

其实这一点在代码仓管理上也存在，Repo的分隔也存在这个问题，前端、多个语言的客户端、API的Yaml文件，进行精细化的管理。但CC、Cursor这样的工具无法看到全貌。

下一个我做的项目，我倾向于使用Mono Repo，充分利用AI工具提交，并且如果是AI相关项目的话，我倾向于使用Python语言。

但是我相信，如果多个系统都能与AI工具对接打通，给AI提供了更加结构化、质量更高的数据，理论上上限要高于所有东西以markdown格式放在代码仓库不同文件夹的做法。

三、工作流程

AI没有改变软件工程，只是把其中的很多工作加速到不可思议的地步。

AI只能加速单人闭环的工作，对人和人的交互没有帮助。

AI 当前的强项，是提升“单人闭环任务”的速度。但当任务涉及跨角色交互时（如开发与测试、测试与运维、产品与开发），AI 的作用显著减弱。

左图是人与人的交互，严丝合缝。如右边两张图所示，AI交付件还不能做到严丝合缝地对接，为了能顺利走完流程，蓝色、橙色，必须得有一方做出额外的工作才行。（当然，为了避免同事说你不靠谱，我还是推荐蓝色方做出额外工作。）

AI时代，应该尽量把一个工作的各个方面交给一个人，这样来减少人与人的交互，充分提高效率。

这和交给Agent足够的上下文的道理是相通的。

来看一个典型案例：微服务开发与测试的协同。一个典型微服务的开发、测试、发布上线流程如下：

产品与开发、开发和运维，这样的问题也存在，以编码举例子，主要是因为时间相对长，矛盾更加明显。

测试负责产品质量的出口，测试在自己的领域范围内，通过自己的理解，对整体的测试进行分层落地（基本接口测试与集成测试环节）。

图中共有四项活动：代码、单元测试、基本接口测试、集成测试。这个模式下，单元测试与基本接口测试存在能力上的重叠。对流程进行了如下优化（测试将测试设计左移，基本接口测试放在开发阶段，弱化单元测试。

从传统领域的角度来看，下面的方式，测试更早介入，且减少了重复工作。但是从AI辅助的角度来看，那个效率更高？

从AI辅助的角度，橙色的环节充斥着大量的交互，诸如代码中书写的测试要匹配测试的设计（通过方法名与用例Id匹配），开发要确认测试设计表达的含义等。当团队想要使用AI提效时，这个矛盾就被放大。尤其是当 模型能力不足 与 信息孤岛 并存时，协作复杂度被进一步放大。

当下，在笔者所在的团队，上下两种流程都存在。上下两种方式那种更好？笔者下意识地觉得当未来AI的生产力突飞猛进的时候，上面的方式会更好（这一判断源于相信人和AI协作的效率会远远大于人和人协作的效率），但是在当下，笔者想不清楚，也给不出答案。当前笔者针对上下两种场景，寻找集成了对应信息源、最合适的工具进行提效。

总得来说，企业要避免陷入 “工具因为流程导致效果不及预期”、”流程不会为没有效果的工具变更，让步”、”开发人员对工具没有信心” 的恶性循环。

总结

AI 在个人层面的高效令人振奋，但企业的整体效率并未出现预期的跃升。问题主要集中在模型能力、信息孤岛与工作流程三方面。前两者可以通过技术投入与资源建设逐步改善，而工作流程的变革则需要企业在思维模式与协作方式上完成真正的转变。