1. coding 方式的变化
以这篇博客的 repo 为例，原来我加入一本正在读的书到书架，需要几个步骤：
- 在豆瓣搜索，找到书籍主页
- 如果书籍来自微信读书出品，豆瓣上可能搜不到，那就需要分析微信读书网页版的书籍主页
- 下载对应封面图片
- 修改 books.yaml 记录时间和图片地址
现在 izualzhy.cn.bookshelf 一个 skill 就搞定了。进一步，借助微信读书的官方 skill，书籍是从哪天开始阅读的、有多少条笔记、每条笔记写了什么，都可以通过 skill 完成了。
原来这种 固定步骤+人工分析 这种规律的工作，现在基本都通过对话完成
再就是平时用到的很多临时脚本，也是用 AI 生成。之前做过比较多代码 review 工作，所以 AI 100 行以内的脚本（没有多层嵌套循环），还可以快速判断出来靠不靠谱。
这种短小的代码，个人 review 相比让不同模型交叉 review 要好很多，因为 AI 对严格程度不好把握，有时候确实有问题，有时候又过于严谨。而且 AI 会大量的考虑封装、参数化、注释、异常分支等等，如果是我临时折腾数据用的，还会在提示词里标明一句：追求简洁，可以写死变量，不用考虑太多。
但是不懂的方向/语言就得格外小心，之前设计了一版页面，让 AI 实现前端，看着正常。但是直到打开 F12-console，才会看到大量报错：2runtime-core.esm-bundler.js:226 TypeError: Cannot read properties of null (reading 'insertBefore')。需要加一层测试更加保险。
所以我觉得伴随 coding 方式的变化，现在 经验变得更重要、测试也更重要：经验决定了过程如何约束，测试决定了结果如何把关。
之前看到有的新闻 QA 合并到 RD 部门，这点我不太理解，跟我的感觉是反的。
2. 知识传递方式的变化
原来画架构图，会刻意去确保色系、对齐是一致的。现在则是先让 AI 生成一版。
比如这是一本原来看过的书籍里的架构图：
让 chatgpt 做了下优化：
优化后确实好看了，但是越是这种图片的文章，比如别急着神化 Loop Engineering：… ，看着反而越要小心。
我现在判断一篇文章是不是 AI 写的，常看的就是图片、表格，有没有浓浓的 AI 风格(当然不是说上一行的公众号文章就是是 AI 写的）。现在看文章，不懂的地方可以问 AI ，这是节省的时间。但是还得先判断下这篇文章是不是纯粹拿 AI 写的+有没有必要看，这是浪费的时间。
所以以后的文章，是不是也要分两类了，花钱可以看人+AI写的，有深度、有独特见解、面向固定受众群的；不花钱，就只能看鱼龙混杂的文章，一不注意看篇电子垃圾还得洗洗眼。
各类聊天 AI ，给我的感觉是一个非常善于发现你知识里的漏洞、但是又非常会迎合你的角色。
这样的后果，就是几轮问答下来，往往是你自己感觉收益良多，因为 AI 先是指出了你之前不那么清楚的知识盲点，然后你搞懂之后，AI 又对你终于理解了赞赏一番，还贴心的问你要不要生成代码要不要继续深入介绍。但就是这样“因材施教”的学习路径，对每个人来说却一定是不同的，所以启发你并不代表能启发别人。
转发几段和 AI 的聊天记录，这和原来直接转了一篇公众号文章没有区别。
基于 AI，我们应当有更好的知识筛选和传递方式，比如让 AI 从各方面（你知道的和你原来不知道的），系统性的整理出来：1. 现状有什么问题 2. 目标做成什么样，3. 1→2 中间有哪些解法，你是基于什么考虑，选择了当前这一种解法。
无论是一个项目，一个想法还是只是一个知识点的梳理，这样才是务实的知识传递。
我也遇到过问为什么这么干，结果直接把跟 AI 对话的截图发了出来，AI 说“建议你这么做”，哭笑不得😂
AI 可以辅助更好的沟通，但是一定要提前学会应该如何更有效的传递知识。
3. 研发范式的变化
研发工作 ≠ coding ;
coding 提效 ≠ 个人 deliver 效率提高 ;
个人效率提高也 ≠ 整个组织效率提高了。
如果组织对于研发效率有量化指标统计，可以试着把之前使用 AI 前后的效率指标对比看看。我看过几篇互联网公司 EE 部门的文章，提效都不太明显。
源头都指向了研发范式没有改变，为了防止用这个模糊的名词来解释/解决这个问题，先举几个例子：
- 一个项目典型的几个角色：PM、RD(FE/BE)、QA、OP 是否出现了互相等待的情况，AI 提效了，但是每个人每个角色提效不同，人在等人
- 项目测试了，但是上线没资源、LLM 网络问题、不符合 OP 对于线上服务的准入标准等，人在等资源
- 人变成了信息的搬运工，AI 给出修改方案，人改代码，部署测试，报错再发给 AI，AI 在等人
从大盘看，都在用 AI；从代码看，代码的 AI 生成率也高的离谱；问问反馈，都觉得 coding 变快了。
可从实际效果看，feature/bugfix 的交付周期变化却不及预期。深入去看，大概都会发现是上述类似的例子。
过去几年，很多公司在讲企业知识库，以及围绕着企业知识库的专家、客服提效，现在来看，对于研发，这个环境需要继续扩大。知识库是静态的，对于研发流程来说，环境必须是可交互的(能够运行程序、读写数据)，整个测试系统的设计需要对 AI 更加友好，那 环境权限、数据权限、CICD、网络 等如何打通，就是一个难而正确的事情了。
同时并且允许不同的业务线采用不同的 AI 接管程度，才能防止人成为信息的搬运工，成为效率的瓶颈点。
好的测试系统，需要实现这个效果:
RD 修改代码 → AI 启动服务 → AI 执行接口测试 → AI 构造不同配置与边界场景 → AI 输出验证结论。
我自己设计 QA workflow 大致是这样的：
你现在是一名 QA，请独立完成一次接口验证。
目标：
1. 自动启动本地服务。
2. 使用预置测试数据调用接口，验证业务逻辑是否符合预期。
3. 分别验证：
- 首次请求（无缓存）
- 再次请求（命中缓存）
4. 根据返回结果确认：
- 核心字段是否正确
- 缓存是否生效
5. 清理缓存，重新构造不同测试场景。
6. 修改配置参数（例如阈值、开关、限制值），验证系统在不同配置下的行为是否符合预期。
7. 调用相关接口验证统计信息是否正确变化，例如：
- 命中次数增加
- 未命中次数增加
- 配置变更立即生效
8. 验证所有相关接口没有出现异常。
9. 最终输出测试报告，包括：
- 每一步验证结果
- 是否符合预期
- 发现的问题
- 建议修复项（如果存在）
在具体实践时，会沉淀为更详细的 skill ，比如启动服务、清理缓存用什么脚本，验证的内容项、设计几个变量来验证接口(决定了 AI 最终结论表格里提供多少个测试样例及结论)
全流程的测试环境打通变得非常重要，业务所在的服务和 AI 执行的环境(Service → Agent → LLM)也需要打通。
所以测试环境也变得更重要，但测试环境如何真实的模拟线上环境，说来话长。以大数据的场景，举几个问题：
- data：大数据里离线表，单个表所有分区加起来，大的有几十PB，测试环境没有这么多资源
- schema：一个 SQL 可能要读十几个表做联合查询，如何确保测试环境的表结构跟线上一致，是否存在只提交单子审核更新了线上表结构，忘了修改测试环境？
诸如此类的问题很多，好处是这些问题不是今天才有，测试和线上环境的隔离以及同步，是一个持续了很久的话题，需要人力、平台化的投入，当然前提是多个团队的 OKR 共识。这个过程知易行难，基于 AI 的背景，或许能更快的达成共识。
很多厂子也都在招全栈工程师，实际上 OPC 和全栈我觉得都是为了避免上述的问题，比如如果还是典型的 RD(FE&BE)、PM、QA、OP 角色，中间经过多次信息传递。即使前提是各方都有 ownership，确保产出的文档质量足够高。但往往是下一个环节的人+AI 看文档，根据想法让 AI 产出文档/业务代码/测试代码，中间带来了：1. 信息的失真，多个环节增加的噪声 ； 2. 效率的降低。
所以我们会不会是“工业时代的纺织女工”，我不知道。但是这条流水线的角色、整体的研发范式是会要改变的。
4. 对人才理解的变化
那效率的天花板在哪？我觉得取决于组织的变化，以及组织对人才的理解。
组织是个复杂的话题，齿轮联动带来的效率变化更复杂。水平有限，只能说说我理解的人才需求的变化。
人需要守住底线、承担代价。
守住底线、承担代价，不是愿意加班跟 AI 不断对话优化代码，那只是返回手写代码的“石器时代”的无用功；也不能只是一句简单的我来解决，那只是无法换来结果的一腔蛮勇。
当然不是说上述情况不好，只是不够 AI Native.
人需要能够判断 AI 是对是错，能定义什么样的结果是对的，什么是好的，能够继续细拆为各个更细粒度的指标。需要能够对验证和评测工程有足够的理解，提高杠杆放大产出；而技术负责人的要求变得更高，如何能够更深入到项目一线，洞察如何平衡效率和质量；如何管理项目，能够根据经验去判断一个需求应该要花多少人力，评估不同需求的不同周期以及 AI 带来的提效成果；如何去管理团队，尤其是管理一个人 + AI 的混合团队。