标签归档：研发效能

AI Coding 时代如何有效度量研发效能

在 AI Coding 时代，当我们说提升效能 50%，从老板的角度，那应该要干掉 50% 的人。

但又不能真这么干，这是一个简单的财务逻辑，也是一种本能的反应。

但研发又不是完全标准化的流水线。AI 在各环节都有提速，但对于需求理解的一致性，线上兜底，发布治理这些环节没法完全同步提速。

人是可以砍，但最终系统脆弱性、技术债务和交付风险一起放大。

以 AWS 为例，公众知道的类似线上故障发生不止两次了。

并且在一些大的公司，也出现了开发人员不知道自己写的是什么的情况，对于大公司一套巨大的工程体系，如果是一个完全的黑盒，没有人知道里面发生了什么，出现大的问题只是迟早的事情。

聊远了点，回到今天的主题，如何有效的度量研发效能。

当我们用上 AI Coding 之后，在上面所说的整体提效的逻辑中，我们需要细化这个效能的度量逻辑。

同样规模的团队，能不能交付更多有效价值，能不能把交付周期压短，能不能在不明显增加事故和历史债务的前提下，把过去做不到的事情做起来。

从指标的逻辑来看，DevOps 里那套大家已经很熟的「四个指标」——部署频率、交付周期、变更失败率、平均恢复时间依然是很能打的一组指标。尤其是 TTM，也就是从需求进入系统到真正产生用户价值的时间，还是王牌指标。

AI 时代，研发效能的核心指标体系要刷新，但不能推倒重来。

整个度量的逻辑不仅仅在于指标，同时也在于到底把指标绑在什么对象上，怎么解释，怎么防止它们被 AI 放大之后失真。

度量谁

一个问题，AI 产出要不要单独度量？

建议是：可以记录，不要单独考核。

因为 AI 没有责任主体。它不会背 SLA，不会参加事故复盘，也不会在需求失败时承担后果。

如果我们把「AI 生成代码占比」或者「AI 采纳率」当核心 KPI，很快就会把团队带进一个很熟悉的坑：为了优化指标而优化行为，最后牺牲真实交付质量。

研发效能度量一定要有清晰主体。这个主体通常有三层：

工程师个体
团队
价值流或产品线

在 AI 时代，我更建议把主分析单位放在团队和价值流，但个体数据也需要通晒，人与人还是需要比较，并且人的实际使用情况也需要观测和度量。

说到个体度量，可能会有人觉得开始卷了，回到了粗暴管理

我觉得个体数据要看，并且要公开到一定程度。否则团队里谁在真正把 AI 用进生产，谁还停留在传统写法，谁能稳定地产出高质量变更，谁在用 AI 快速制造垃圾代码，管理层根本看不见，辅导也无从下手。问题从来不在于能不能比较，问题在于拿什么比较，以及比较之后准备用它干什么。

可以把「个体可观测」和「个体直接考核」分开。前者要做细，后者要克制。个体层的数据主要解决三类问题：第一，识别使用差异。第二，识别能力短板。第三，识别风险人群。比如有的人 AI 使用频率很高，但交付周期没有改善，返工率还在上升，这通常不是工具问题，是任务拆解、约束描述、结果校验出了问题。还有一种人，表面上 AI 使用不多，但需求稳定、事故极少、关键模块掌控力强，这类人往往承担了大量隐性复杂度，单纯看「人均产出量」会被严重低估。

所以个体层该看的，不是「生成了多少」，而是「借助 AI 之后，个人交付行为发生了什么变化」。可以重点盯几组数据：需求从领取到合并的中位时长、PR 平均大小、评审往返次数、回退率、线上问题关联率、测试补充情况、跨模块变更占比、AI 建议采纳后的修改幅度。这里面真正有价值的，不是某个数字本身，而是前后变化和人与人之间的分布差异。一个人 AI 采纳率高，不说明他强；采纳率高、评审一次过、上线后稳定，这才说明工具真的转化成了产能。反过来，另一个人采纳率也高，但 PR 越来越大、review 来回打架、上线后热修频繁，这种数据就已经在报警了。

个体数据为什么要通晒？

团队协作里，很多能力本来就是相对的。谁的需求吞吐稳定，谁总能把复杂变更压在可控范围里，谁的变更老是把测试链路打爆，谁对 AI 的依赖已经超过了校验能力，这些不能永远藏在「一团和气」后面。通晒的价值是建立真实参照系。工程团队里最怕的一种状态，是大家都觉得自己做得差不多，实际上产出质量、稳定性、问题密度差了一倍以上。数据如果不拉平，组织就只剩印象管理。

当然，个体通晒有前提。第一，口径必须统一。第二，不能只晒单一指标。第三，必须配上下文。比如一个人长期负责遗留系统改造，变更失败率高一点、交付周期长一点，很正常；另一个人长期做边缘功能，吞吐高也不稀奇。脱离任务难度做横向比较，最后一定会逼着大家抢简单活。我的经验是，个体层至少要把任务类型、系统风险等级、需求大小这几个维度一起带上。不然表面上是在做精细化管理，实际上是在奖励投机。

团队层和价值流层还是主轴，因为真正的交付结果最终只能在这两层闭环。一个工程师再强，也没法单独决定发布窗口、联调效率、测试环境、跨团队依赖和灰度策略。AI 时代尤其如此。代码写快以后，瓶颈更容易从个体编码能力转移到团队协作和系统机制上。所以如果一个团队整体 TTM 没降、变更失败率在升、MTTR 也没有改善，那就算团队里有几个人个体数据很亮眼，也不能说明这个组织真的变快了。很多管理者容易被「明星工程师 + AI」的局部高产迷惑，这是很危险的。效能度量最终看的是系统，不是看谁在局部冲得猛。

价值流这一层更关键，因为它决定了管理层看到的是局部繁荣，还是真实效率。一个需求从业务提出到用户可用，中间穿过产品、研发、测试、运维、合规、数据、客服，任何一个环节卡住，前面所有 AI 提速都白搭。很多团队以为自己效能不差，问题出在开发不够快；把价值流拉直一看，开发可能只占整个周期的 20%。剩下 80% 都耗在等待、确认、返工和协调上。这个时候你还在研究个人 AI 采纳率有没有上去，说实话，方向已经偏了。

所以，三层都要度量，但角色不同。

个体层，解决的是识别差异、暴露问题、推动辅导。
团队层，解决的是交付责任和工程能力。
价值流层，解决的是端到端效率和组织瓶颈。

如果非要再说得更落地一点，可以这样处理：

个体层数据全量采集，有限通晒，谨慎用于绩效
团队层数据作为正式经营指标，进入月度复盘
价值流层数据进入管理层决策，用来推动跨部门改造

这里还有一个问题：AI 使用情况本身，确实会逐渐演化成个体能力差异的一部分。今天还可以说是工具习惯差异，再过一段时间，它会越来越接近工程生产方式差异。有人能用 AI 快速完成问题拆解、方案比选、代码生成、测试补全、文档整理，再自己完成严格校验；有人只是把 AI 当高级补全，甚至生成什么就提交什么。两者的产出质量和成长速度，一定会拉开。这个差异如果不观测，组织是在主动放弃识别新能力结构的机会。

还是那句话，观测不等于迷信，比较不等于唯排名论。个体层数据要服务于两件事：培养更强的人，提前发现风险。它不能把团队带回那种老派的、只会按数字压人的管理习惯。因为 AI 时代最不缺的，就是表面上很漂亮的数字。真正缺的，是能把这些数字放回具体工程语境里解释清楚的人。

量结果

我一直不太赞成把研发效能拆成「过程指标 vs 结果指标」两个完全对立的东西。工程里没这么清楚。很多大家嘴里的结果指标，实际上掺了很多过程含义。代码行数就是典型例子。

很多人说 LOC 已经过时，这话只说了一半。更准确一点：LOC 从来就不是好的一线效能指标，在 AI 时代更差。

原因有三个。

生成成本塌了：过去一个人写 500 行和写 50 行，投入成本通常不同。现在 AI 补全、生成、重构、搬迁代码，几分钟就能吐出成百上千行。代码行数和人类投入的相关性被打穿了。
噪音变大：AI 很容易生成「看起来很完整」的实现：参数校验、日志、适配层、重复样板、冗余抽象全都给你带上。LOC 涨得飞快，但业务价值未必增加。
债务被掩盖：最麻烦的是第三点。AI 会让代码库存增长速度明显快于架构治理速度。表面上看，产出变高了；往后看，维护成本、理解成本、回归成本都在涨。LOC 会把这个问题盖住。

所以代码行数其实没有啥意义，只当成代码影响范围的辅助信号，别当产出指标。

那真正该量什么结果？

可以分三类。

交付结果

这是最基础的一层：

需求交付数量
需求交付周期
按期上线率
有效发布次数
版本回退率

这里要提醒一下：上线需求数也很容易失真。
因为需求切得越碎，上线数越好看；但碎到一定程度，用户感知价值可能没有提升，反而多了协调成本。

所以需求数量一定要配合需求粒度标准化。最少要把需求分成几类：小修复、小功能、中型功能、跨系统项目、技术治理项。不同类型分开统计，不然一张表里什么都看不出来。

业务结果

如果团队做的是业务研发，最终还是得往用户影响上落。常见的：

某类功能从提出到用户可用的时间
用户覆盖范围
功能使用率
转化率变化
关键漏斗改善
客诉下降
线上稳定性对收入的影响

很多技术管理者不敢碰业务指标，怕研发背锅。我反而觉得该看，但不要简单归因。业务结果可以做关联分析，不要粗暴做责任归因。比如某个推荐功能两周上线了，但实验效果一般，这不等于研发效能差。研发效能差，应该体现在 TTM 过长、试验成本过高、回滚困难、迭代慢，而不是实验结论本身不好。

工程结果

如果团队做的是平台、基建、中间件、工具链，不能硬套 GMV、转化率这种业务指标。这个场景下我更看这些：

接入团队数
接入周期
平台能力调用成功率
构建时长变化
测试时长变化
故障发现提前量
资源成本变化
事故数和事故影响面
研发人均可支撑服务数

基建团队最吃亏的一点，是价值释放往往滞后，而且分散在别人的效率提升里。如果你只盯上线需求数，这类团队会被系统性低估。

TTM 还是核心指标

如果只能保留一个指标，我还是会选 TTM。

这里说的 TTM，不是立项到上线的日历时间，而是价值从进入研发系统到到达用户手里的有效时间。很多公司嘴上讲敏捷，实际上量的是开发开始到提测结束，这根本不是 TTM。

为什么 TTM 在 AI 时代更重要？

因为 AI 最直接改变的，就是局部生产速度。代码写快了，单测补得快了，文档初稿也快了。问题是，这些加速会不会真的传导到业务价值交付，完全不确定。

我见过最典型的一种情况：

开发编码时间下降 40%
PR 数量上涨 2 倍
评审负担上涨 60%
测试回归时长上涨 35%
发布前冻结窗口变长
最终需求上线周期几乎没变

如果你只看编码侧的数据，会得出一个完全错误的结论：AI 大幅提升了效能。
如果你看 TTM，问题一下就暴露了：加速发生在局部，瓶颈转移到了下游。

所以 TTM 的价值就在这里。它不关心你用了什么先进工具，它只看最终有没有把价值更快交出去。

TTM 怎么拆

TTM 不能只看一个总时长，否则只能看热闹。要拆段看：

需求澄清耗时
方案设计耗时
开发耗时
评审耗时
测试耗时
等待发布耗时
灰度验证耗时

拆完之后，你才知道 AI 真正帮到了哪一段，堵在了哪一段。

另外，在 AI 时代，这种拆段是否合理，是否可以合并不同阶段或角色，让一些信息的流转内化为个人的思考逻辑，实现端到端的 AI 化。

比如，产品经理直接从需求到前端代码的实现。

看分布，不看均值

TTM 最忌讳只看平均值。平均值非常会骗人。正确看法至少要有：

P50
P75
P90
超过阈值的长尾需求占比

因为 AI 往往会优先优化简单需求。这样 P50 可能很好看，P90 反而更差。原因也简单，简单需求被快速吞掉之后，系统里剩下的都是复杂需求、遗留系统改造、跨域联动项目，长尾会更长。

如果你只看均值，会误判整个系统在变快。

四个指标

DevOps 四指标在今天依然能打，但口径需要有一些升级。

部署频率

部署频率比 LOC 强太多。因为它至少是靠近真实交付动作的。代码写了多少行没人关心，真正有意义的是你有没有把变更安全地推到生产环境。

但部署频率也不能裸看。

高频不等于高效

AI 上来之后，一个常见变化就是团队更愿意切小 PR，发小版本。这个方向本身没问题，小批量交付通常更安全。问题在于，有些团队把一个正常需求拆成大量低价值、低独立性的碎发布，频率上去了，用户价值没上去，测试和发布成本反而更高。

所以我一般会同时看三个维度：

单位时间部署次数
每次部署的有效变更量
每次部署的独立可验证价值

没有后两项约束，部署频率很容易变成表演数据。

适用场景不同

业务团队和基建团队的部署频率口径也不能完全一样。

业务团队可以看：

每周或每日生产发布次数
灰度发布次数
从功能完成到触达用户的次数

基建团队更适合看：

核心服务变更发布频率
非工作时段紧急发布占比
配置变更自动化发布比例
平台工具链版本迭代频率

基建团队很多时候更强调稳定和兼容，追求极端高频未必合理。比如数据库、中间件、网关这类系统，频率太高反而可能说明变更管理有问题。

交付周期

交付周期本质上是 TTM 在工程流水线里的展开版。通常从代码提交到生产运行，也有人从需求进入开发开始统计。具体口径可以按团队定，但必须固定。

AI 时代交付周期最容易出现两个假象。

提交变快了，交付没变快：这是前面说的局部提速问题。AI 让提交更快，但后续验证没跟上，周期不会实质下降。
PR 变多了，周期看起来更短：如果团队把一个需求拆成多个极小 PR，每个 PR 周期都很短，报表会很好看。但从需求视角看，整体仍然很慢。所以我建议同时维护两套口径：一个是 PR 级交付周期，另一个是需求级交付周期。PR 级用于观察工程流水线摩擦，需求级用于看真实业务交付。只看其中一个，都会失真。

变更失败率

这个指标在 AI 时代的重要性实际上上升了。

因为生成式编码提高了变更速度，也提高了「错误以正确形式出现」的概率。以前很多错误是写不出来，现在是能很快写出一个逻辑闭环、风格统一、还能过部分测试的错误实现。它更隐蔽，也更容易通过表面检查。

可以把变更失败率定义得更工程化一点，至少包含这些事件：

发布后触发回滚
发布后引发 Sev 事故
发布后触发热点修复
发布后造成核心指标异常
发布后引起客户可感知故障

如果定义太窄，只算重大事故，这个指标会钝化。定义太宽，又会把正常试错算进去。团队需要自己定边界，但边界一旦定了就别频繁改。

AI 对失败率的影响机制

这里有几个常见来源：

生成代码对边界条件覆盖不足
引入不必要抽象，增加理解偏差
与历史代码风格和隐式约束不一致
测试代码同样由 AI 生成，出现「同源缺陷」
变更面比工程师主观预期更大

我自己比较警惕第四点。很多团队现在喜欢让 AI 顺手补测试，看起来很完整。但如果实现和测试都建立在同一段错误理解上，测试通过并不能证明正确。

所以在高风险变更里，测试不能只依赖生成。关键路径一定要有人做反例设计。

平均恢复时间

很多团队对 MTTR 的重视程度不够，尤其是业务团队。实际上，AI 时代恢复能力的重要性在上升。

当代码生成速度变快，进入生产环境的变更更多、更碎、更频繁，系统面对故障的概率和复杂度都在变化。你不一定能把每次变更都做得完美，但你必须能快速止血。

MTTR 的价值在于衡量团队是否真正具备工程韧性。这个指标背后对应的是一整套能力：

监控和告警是否有效
变更是否可追踪
是否支持快速回滚
灰度和开关能力是否完善
值班机制是否靠谱
故障定位信息是否充分

很多团队前面三个指标都好看，MTTR 很差。这样的系统经不起规模化 AI 变更。因为一旦出事，恢复慢会把前面所有频率和周期优势全吃掉。

历史债务

AI Coding 真正会在一年后把团队拉开差距，这里的差距在于谁更早处理历史债务。

这个问题现在还没有被足够重视。但是实际中已经越来越严重了。

因为短期内 AI 会制造一种繁荣感：交付更快，PR 更多，需求吞吐上升。可如果代码库质量、模块边界、测试资产、文档一致性没有同步改善，债务会以更快速度积累。

AI 会怎样放大债务

几个很典型的模式。

重复实现增多：工程师直接让 AI 在局部上下文里生成功能，很容易绕过现有抽象和公共能力。短期最省事，长期就是重复轮子到处长。
中间层膨胀：AI 很擅长生成 adapter、wrapper、facade 这类看起来规整的中间层。问题是很多层根本没有必要，只是为了让局部代码更顺。半年后系统会变得非常厚，排障和重构都很痛苦。
测试资产劣化：生成测试很快，真正有效的测试不快。团队如果只追求覆盖率，很快就会积累大量低价值测试：断言脆弱、依赖实现细节、执行慢、维护成本高。最后 CI 时间越来越长，大家开始跳过测试。
文档与实现漂移更快：AI 可以快速生成设计说明、变更记录、接口文档初稿。但只要流程里没有强约束，这些文档过几周就过时。文档数量增加，不代表知识管理更好。
债务怎么量：技术债务很难精确，但不代表不能量。至少看四组信号：
- 重复代码比例或重复能力点数量
- 关键模块复杂度变化
- 测试执行时长与稳定性
- 历史模块变更失败率和恢复时长

指标落地

说一堆指标，如果最后只是做一张月报，那基本没用。研发效能度量要落地，大概可以看三点：统一口径、自动采集、和决策绑定。

统一口径

很多团队最大的问题不是没数据，是每个人嘴里同一个词代表不同意思。

比如「交付周期」，有人从排期开始算，有人从开始开发算，有人从代码提交算。你拿这三种数据做横向比较，结论一定错。

所以第一件事就是给每个指标下工程定义：

起点是什么
终点是什么
谁负责标记状态
异常情况怎么处理
统计周期是什么
看均值还是分位数

这一步很枯燥，但躲不过去。没有口径统一，报表越华丽越危险。

自动采集

凡是靠人手填的效能数据，最后都会漂。

我建议优先从这些系统自动取数：

需求系统
Git 仓库
CI/CD 平台
测试平台
线上监控与事故系统
发布平台
值班和告警系统

AI 时代还可以补一些辅助数据，比如：

AI 建议采纳率
AI 生成代码在最终提交中的占比
AI 相关变更的回退率
AI 生成测试的失败分布

但这些只建议做诊断维度，不建议直接进核心看板。

和决策绑定

指标如果不进入真实决策流程，就只会变成汇报材料。

可以把不同指标绑定到不同节奏：

周维度

团队看流水线摩擦：

PR 周期
构建失败率
测试时长
发布次数
热修次数

月维度

管理者看交付和稳定性：

TTM 分布
部署频率
变更失败率
MTTR
技术债务信号

季度维度

看结构性问题：

跨团队依赖导致的等待占比
核心系统复杂度变化
自动化覆盖关键路径的比例
平台能力复用率
人均支撑规模变化

只有当指标驱动了人力投入、架构治理、流程调整，度量才算产生价值。

常见误区

误区一：拿 AI 使用量替代研发效能。比如：人均每天调用 AI 多少次，AI 生成了多少代码，采纳率多少，这些数据可以看工具渗透率，不能代表团队变快了，更不能代表交付变好了。高采纳率有时候只是因为团队在写更多样板代码。
误区二：把效能问题当管理问题。一看到周期长，就加日报、加审批、加同步会。这个思路在 AI 时代更危险，因为编码加速之后，组织摩擦会成为主要瓶颈。继续加管理动作，只会让非编码时间更长。效能最后还是要回到工程根上：架构边界、测试自动化、环境一致性、发布能力、可观测性、模块治理。
误区三：把所有团队放在一套指标下排序。业务、基建、平台、安全、数据团队的工作性质差异很大。统一看板可以有，统一排名很容易把组织带偏。
误区四：只看短期提速，不看长期维护成本。 AI 最容易制造的错觉就是这个月吞吐上涨了，于是大家默认效能提升。可如果未来三个月回归变慢、故障变多、重构困难，这个月的漂亮报表只是透支。
误区五：只看平均值。平均值会把长尾、异常、结构性阻塞全部抹平。工程管理里，很多真正该解决的问题都藏在 P90 之后。

最后

研发效能从来不是一个分数问题，它是一个约束系统问题。得回答下面的问题：

价值有没有更快交出去
变更是不是足够安全
出问题能不能快速恢复
现在的速度有没有透支未来

这四件事里，TTM 仍然是排第一的。因为业务不会为你写了多少代码买单，也不会为你调了多少次 AI 买单。业务只关心一件事：价值多久能到用户手里。

AI Coding 改变了工程生产函数。

但它没有改变研发效能的基本物理规律。局部速度不等于系统速度，生成能力不等于交付能力，短期吞吐不等于长期效率。

不要急着发明一套全新的效能宗教。先把工程里的主干指标守住，把主体放对，把业务团队和基建团队分开看，把技术债务纳入视野，再去观察 AI 到底在哪些环节真的创造了增益。

这样量出来的数据，才能指导决策。否则报表再热闹，也只是另一种噪音。

以上。

Cursor AI 编程让我的编码效率提升了 10 倍

从 2022 年 6 月底正式上线的 GitHub Copilot 开始，AI 编程逐步开始进入工作的环境中，开始成为一个真正的 Copilot。据当时微软的评测报告以及当时公司内部使用的问卷反馈调查显示提升效率大概在 10% ～ 30%。

这一数据在当时已经令人惊叹，但随着大语言模型的飞速发展，以及 Cursor、Windsurf 等新一代 AI 编程工具以更直接的 IDE 方式的加入，效率提升的天花板被彻底打破。

从个人体感来说，部分场景有超过 10 倍的提升，特别是通用类功能实现，如爬虫、CRUD 功能、脚本类处理等。但并不等于以前一个项目要 10 个人，现在只需要 1 个人了，毕竟编码在整个项目过程中只占用的时间资源的一部分。

而且，这里的提升并不是说给 AI 说一句话：「给我完成 XXX 功能」，就能直接提效 10 倍，当前阶段，我们还需要有一些使用技巧才能较好的使用 AI 编程，让 AI 编程成为一个实实在在的助手。以下为过程中的一些注意事项和一些可能遇到的问题。

1. 使用 AI 编程的注意事项

1.1 不要求一次性完成所有的工作

AI 编程工具暂时并不擅长处理复杂且模糊的任务，而是更适合解决清晰、具体的小问题。因此，任务分解是高效使用 AI 编程的第一步。

如何实现？

需求分解：将大任务拆解为小模块，可以人工分解，也可以让 AI 协助分解。例如：
- 开发一个后端服务时，可以分解为：数据库表设计、路由框架搭建、业务逻辑实现、测试用例编写。
框架优先：先让 AI 生成代码框架，例如接口的骨架代码、类和方法的定义，然后再逐步实现具体功能。

以一个简单的任务管理系统为例，你直接告诉 Cursor 「帮我实现任务管理功能」，他会提示你给出更多的输入，比如所要使用的技术栈等等，如果我们输入：请用 python 语言作为后端，vue 作为前端帮我实现任务管理功能。他会给出完整的看起来可以使用的架子，实际不太能用。

如果是在一个已有项目的基础上增加模块，以 CRUD 管理任务来说，较好的做法是：

分解需求：
- 第一步：设计任务表（表结构设计），也是明确核心需求的过程；
- 第二步：实现核心的接口和界面；
- 第三步：添加权限管理，一般是有权限体系，可以给参考或者表结构之类的实现；
逐步实现：
- 先让 AI 生成数据库表的定义，明确需求及约束；
- 再生成 API 的路由框架。
- 最后逐一实现各个功能模块。
- 在各功能模块上再扩展其它的需求，如在任务添加的时候要调起弹性接口去完成任务等。

1.2 明确和细化需求

明确和细化需求和第一点有一些不同，这里所要表达的是我们在需求描述时要尽可能的明确和细致，以及需要有我们的转化和理解。

当前阶段，我们用 AI 编程并不是把产品需求扔给 AI，而是我们思考过整个实现的过程，有自己的认知后让 AI 来做会更好，当然，这个思考的过程也可以让 AI 来辅助。

明确需求的层级

假设你需要实现一个用户登录功能，可以先从高层次的需求入手「实现用户登录功能」，然后逐步细化为：
- 数据库中需要存储哪些信息？
- 前端需要提供哪些输入？有没有什么安全输入策略？
- 后端服务的接口设计是什么样的？格式是怎样的？返回码规范是怎样的？
- 需要哪些验证逻辑？使用 JWT 还是 Auth2.0？有哪些安全策略？
细化到函数级别

在某些情况下，有必要直接将需求分解到函数的输入输出、核心逻辑或算法。比如：
- 函数应该接受哪些参数？
- 输出的结果应该是什么样的？是什么类型的数据结构？
- 核心逻辑是否需要特殊的算法优化？

以上这个细化的过程也是个 AI 交互的过程，从大到小，从整体到部分，逐步完成整个需求。

在使用 AI 编程的过程中，确定需求并细化需求是最难，也是整个过程中最复杂的环节，因为它是对现实世界的建模。

把产品需求没有歧义的描述出来，这个过程远没有很多人想象中那么简单。期待 AI 进一步进化后能优化这部分理解的工作。

1.3 善用 AI 的上下文记忆

AI 编程的生成效果在很大程度上依赖于上下文信息。

Cursor 支持上下文记忆功能，可以根据当前项目的代码结构或对话历史生成更精准的结果。并且对于已有代码的项目，提供示例代码给 Cursor 参考，可以帮助它更好地理解项目的整体风格、编码规范以及约定。

参考已有代码

比如，我们可以将公司内部的编码规约或项目约定通过已有代码的形式提供给 AI，这样生成的代码更符合项目需求，减少后续调整的工作量。
让 AI 理解当前代码环境

在和 Cursor 对话时，可以特别的指出关键代码片段（如数据模型、核心函数），这种方式是为了规避 LLM 的上下文记忆的限制问题，突出当前要解决的问题和场景。
补充上下文

如果项目中有复杂的业务逻辑或特定的技术约定，可以通过注释、文档或已有代码的形式向 AI 提供相关背景信息。这样，AI 生成的代码不仅能够「跑通」，还更贴近实际需求。如使用 Cursor 的 @ 符号，除了本地的代码、文档、还可以有多模态的图片、外部链接的文档，Web 网页等等。

2. AI 编程使用中的问题及解决方案

在使用 AI 编程工具（如 Cursor、Windsurf 等）时，尽管其效率提升显著，但也有一些问题亟待解决。

2.1 额度不够了

以 Cursor 为例，即使在不大量使用的情况下，Pro 版本（如 GPT-4、GPT-4o、Claude 3.5 Sonnet 的高速请求）两周内就可能用完额度。高级模型的调用成本较高，尤其是当需要生成大量代码或反复调试时，消耗会非常快。

解决方案：

分工明确，优化工具使用场景
- 代码相关任务交给 Cursor：专注于代码生成、函数实现等任务，减少对 Cursor 的非核心调用。
- 知识性问题交给 ChatGPT或其它大语言模型：对于纯知识性或逻辑性的问题，使用 ChatGPT 或其他不限量的模型（如 GPT-3.5 免费版本）来查询。
分层实现代码
- 先写框架：在开发项目时，先用 Cursor 生成代码框架，明确主流程。
- 逐步细化：将需求明确的函数（尤其是复杂的小块代码）交由 Cursor 实现，而非一次性生成庞大的代码段。
结合其他无限制的大模型
- 对于通用型函数（如工具类代码、简单的逻辑实现），可以利用免费的语言模型完成。
- 配合使用多个编辑器（如 Windsurf 、Cursor、豆包），减少单一工具的使用频率。
节约上下文消耗
- 避免在上下文中反复输入无关信息，尽量精简对话内容。
- 善用工具内的上下文管理功能，如 Cursor 提供的 Add context 或 @ 引用功能，将关键信息外部化，减少重复输入。

当然，对于不差钱的小主来说，可以忽略此问题。

2.2 上下文限制：会「失忆」

当前的 LLM 上下文窗口有限，当输入信息超出限制时，模型可能会「遗忘」之前的内容。这种「失忆」表现尤其明显，例如在多次会话后，最前面的一些关键信息可能会被遗忘，导致生成的代码出现不一致的问题。

解决方案

简要总结关键信息
- 当模型开始「失忆」时，可以总结项目的关键信息并重新输入。例如，核心配置或表结构可以作为关键信息，在对话开始时就输入给 LLM，确保其随时可用。
外部化核心信息
- 将一些不变的核心信息（如数据库表结构、配置文件、接口定义等）存储到单独的文件中。
- 在对话中通过 @ 或 Add context，将这些文件动态添加到上下文中，避免重复输入。
引用外部文档
- 将外部帮助文档、链接或者参考资源作为上下文的一部分添加到对话中。例如，直接粘贴代码库的 README 文件、API 文档链接等，可以帮助模型更好地理解当前任务。
- Cursor 自身支持这些外部的引用，具体方法参见 Cursor 的帮助文档，探索上下文扩展功能。
优化上下文使用策略
- 尽量减少对话中的无关内容（如闲聊或冗长描述）。
- 定期总结对话内容并清理上下文，确保关键信息占用优先位置。

2.3 修改代码混乱：会改乱代码

AI 工具在生成代码时，可能覆盖或修改原有代码，导致逻辑混乱，甚至出现功能性错误，一不小心原来能跑通的功能就不通了。这种情况常发生在对已有代码进行修改时，尤其是在多次修改的情况下。

解决方案

结合版本控制工具
- 在完成每一阶段的明确功能后，及时使用 Git 提交代码，确保已有的工作成果被保存。
- 在尝试新的修改时，可以创建分支或临时提交，确保不影响主分支的代码完整性。
分步引导 AI
- 避免一次性让 AI 修改大量代码，而是按功能模块逐步进行修改。例如，先让 AI 修改某个函数，再验证其效果，而不是直接让它大规模重构代码。
生成新代码替代旧代码
- 在涉及复杂逻辑的修改时，建议让 AI 生成新的代码片段，而不是直接修改现有代码。我们可以手动选择将新代码合并到项目中，避免出现覆盖错误。
代码审查
- 对 AI 生成或修改的代码进行人工审阅，尤其是涉及关键逻辑的部分，确保生成代码符合预期。

2.4 无法解决复杂问题：可能进入死循环

在调试复杂问题或某个难点时，AI 工具可能陷入死循环，反复尝试生成代码但无法有效解决问题。例如，AI 对某个 bug 的修复建议多次尝试后仍然无效，甚至可能导致代码更加混乱。

解决方案

重新整理问题
- 如果问题复杂而模糊，先关闭当前对话，重新开启一个新的会话。
- 将问题简化为多个子问题，并逐步整理关键信息后输入给 AI。例如，将错误日志、上下文代码片段和预期行为整理成清晰的描述。
结合搜索引擎
- 对难以解决的问题，可以将错误信息、bug 的关键描述扔给搜索引擎，结合开发者社区（如 Stack Overflow）寻找答案。
- 搜索的过程中可以收集更具体的上下文，再反馈给 AI，增加其解决问题的可能性。
寻求多工具协作
- 如果单个 AI 工具陷入死循环，可以尝试切换到其他工具或模型。例如，Cursor 无法解决的问题，可以切换到 ChatGPT 或 Claude 进行尝试。
- 结合传统的调试手段（如 IDE 的调试功能、日志分析工具等），帮助定位问题。
分阶段测试
- 将复杂问题拆解为多个小问题，逐步测试每一部分的结果。例如，如果某个模块的逻辑无法正常运行，可以先测试其输入输出，再逐步调试内部逻辑。

3. 小结

用 AI 编程，也就是和 AI 协作，本质上是一种双向的沟通过程。

我们需要像与团队成员协作一样，清晰表达需求、提供必要的背景信息，并通过持续的反馈和迭代优化，逐步引导 AI 生成符合预期的结果。只有做到有效沟通，AI 才能真正成为开发者的高效助手，而不是一个需要频繁纠错的工具。

以上。

研发效能之规模管理：工程化与系统化的思考

随着业务的发展，研发团队和系统架构往往面临一个共同的难题：如何在规模不断扩大的情况下，保持高效、稳定的输出。

你是否曾经历过这样的困境：系统运行环境中的负载不断攀升，不得不频繁进行性能优化；团队规模扩充后，开发协作开始变得混乱，沟通成本直线上升；技术债务不断积累，系统的开发和维护变得艰难？

这些问题的本质在于规模管理的缺失或不足。规模不仅仅体现在系统需要处理越来越多的用户和数据层面，还包括团队管理、开发流程和技术栈的复杂性增长。如果缺乏系统化和工程化的管理方法，规模的扩大往往会拖慢研发效率，甚至导致项目失控。

那么，如何通过系统化、工程化的手段，来解决规模扩展带来的复杂性和挑战呢？

1 研发中的规模

在软件研发中，规模主要可以分为生产规模和开发规模两大类。具体来说，研发中的规模主要包括以下几个方面：

1.1 生产规模

生产规模指的是系统在实际运行环境中所需处理的负载、并发能力和扩展性。它关注的是一个系统在面对业务增长时，是否能够高效处理不断增加的数据量、用户请求、并发任务等。包括：

并发处理能力：系统可以同时处理多少用户请求或任务。
数据处理能力：系统能够处理的数据量级别如何，是否支持大数据量的存储、查询和分析。
网络流量承受能力：系统在面对大规模用户访问时，是否能够保持稳定的响应时间，并在流量高峰期依然能够正常工作。
弹性扩展能力：系统是否可以根据流量的变化自动扩展资源，避免高负载时的性能瓶颈和低负载时的资源浪费。
容错与高可用性：系统在面对硬件或软件故障时是否具备自我恢复能力，确保业务的连续性。

1.2 开发规模

开发规模指的是随着项目和团队的扩展，如何有效管理代码库、开发流程和团队协作。随着开发人数、代码库复杂度的增长，团队需要更加系统化的管理手段，以保持高效的开发效率和高质量的代码输出。

代码库规模：项目的代码量逐渐增加，模块和功能变得更加复杂。如何确保代码库的可维护性、可测试性和可扩展性是关键。
团队规模：参与开发的工程师人数增多，如何确保团队成员高效协作、避免冲突和重复工作是管理的重点。
协作复杂度：随着团队规模扩大，沟通和协作的难度也会增加。如何通过协作工具、流程规范和文档化手段确保团队高效运转。
开发流程的复杂度：团队规模和项目复杂度增加，开发流程自然也会变得更复杂。如何通过流程优化和工具化手段（如CI/CD、自动化测试等）简化开发、测试、发布流程。
知识管理：随着项目复杂度增加，技术债务和知识流失的风险也随之增加。如何通过文档化、知识共享平台等手段，确保团队成员（尤其是新人）快速上手和理解项目。

除了上面的 5 点，还有一些技术规模相关的点：

技术栈的扩展性：技术选型是否具备支撑未来业务增长的能力，是否容易扩展、维护和升级。
基础设施的扩展性：从服务器、数据库到网络架构，是否能够支持高并发、大数据量、快速响应等需求。
技术债务管理：随着项目的发展，技术债务的积累不可避免。如何在技术规模扩展的同时进行技术债务的管理和偿还。

2 如何管理规模

作为研发管理者，面对系统和团队规模的不断扩大，如何确保研发效能的持续提升，是一个复杂且多维度的挑战。规模管理的核心在于通过技术手段与管理方法的结合，保证系统和团队能够适应业务增长，同时避免因规模扩大而带来的效率损失和质量问题。

2.1 管理生产规模

生产规模通常指的是系统在实际运行环境中所能处理的负载、并发能力和扩展性。然而，生产规模的扩展实际上离不开架构、基础设施、自动化手段等，即通过技术手段来保证系统能处理不断增长的业务需求。

2.1.1 架构设计与扩展性

生产规模的扩展依赖于架构设计的弹性和扩展性。架构设计是生产系统能否承载更大负载、更高并发的根本。

微服务架构：在面对大规模扩展时，单体架构往往难以承受较大负载和频繁的变更。微服务架构通过将系统拆分为多个独立的服务，每个服务可以独立扩展、部署和维护。这种架构设计允许生产系统根据业务需求水平扩展，避免单点瓶颈。
事件驱动架构：在高并发环境下，事件驱动架构可以通过异步消息处理来解耦系统中的模块，从而提高弹性和扩展性。这种架构设计允许系统通过消息队列（如Kafka、RabbitMQ）来处理大量并发请求，并减少同步通信带来的延迟和性能瓶颈。
分布式架构：对于需要处理海量数据和高并发请求的生产系统，分布式架构是必不可少的。通过水平扩展（如分布式数据库、分布式缓存、分布式存储等），系统可以在生产环境中扩展以应对更高的负载。

架构设计决定了生产规模的技术上限。架构设计是生产系统能否在负载增加时保持高效运行的关键。

在管理生产规模时，需要着重考虑当前架构的合理性和前瞻性。

2.1.2 基础设施扩展和性能优化

自动化扩展：利用云计算平台的弹性伸缩功能，根据流量动态增加或减少资源。为了实现更灵活的资源管理和扩展，容器化技术（如 Docker ）和容器编排系统（如 Kubernetes ）成为生产规模扩展的基础。通过容器化，生产环境中的服务可以快速部署、扩展和迁移，从而应对瞬时的流量峰值。同时，Kubernetes 的自动扩展功能可以根据资源的使用情况自动调整服务的实例数量，确保系统在负载变化时能够灵活响应。
缓存与 CDN：在高并发访问场景下，合理使用缓存（如Redis、Memcached）和 CDN 可以显著减轻后端的压力，提升系统的响应速度。缓存机制不仅加快了数据的读写，还减少了数据库的压力。
技术栈的性能和扩展性：技术选型中的语言、框架和数据库等技术栈的扩展性直接决定了生产系统的性能瓶颈。例如，选择支持大规模并发请求的技术栈（如 Node.js、Go、Java 中的 Netty 框架等）可以显著提升系统在高负载下的表现。同时，选择可扩展的数据库技术（如 NoSQL 数据库、分布式数据库）可以确保系统在面对海量数据时依然能够快速响应。当确实存在性能问题时，换一种技术栈可能是一种比较彻底的解决问题的思路。
性能监控与优化：生产规模的管理离不开实时性能监控。通过监控工具（如Prometheus、Grafana）监控系统的关键性能指标（如CPU、内存、带宽、响应时间等），并通过自动化告警机制及时发现并解决瓶颈问题，确保系统的稳定性和高效性。
云计算与弹性扩展：云平台提供的弹性扩展能力是生产规模扩展的重要技术基础。通过云服务（如阿里云、腾讯云、AWS、Azure、Google Cloud）提供的按需扩展资源，生产系统可以根据流量动态调整计算资源、存储资源和网络带宽，确保系统在高并发和高负载下保持稳定。

基础设施扩展能力和性能优化及监控直接影响生产系统的弹性和可扩展性。合理的选型能够为生产系统提供未来业务增长所需的技术保障。

2.1.3 自动化与运维能力

生产规模的扩展离不开自动化运维能力的支持。自动化工具链（如 CI/CD、自动化测试、基础设施即代码）是保障生产系统在扩展过程中保持高效运作的重要手段。

持续集成与持续交付 (CI/CD) ：在生产环境中，频繁的更新和部署可能会带来较高的风险。通过CI/CD工具链，生产系统的更新、测试和部署可以自动化完成，从而减少人工操作带来的错误和延迟。CI/CD工具确保在生产规模扩展的过程中，系统的更新频率不会影响其稳定运行。
自动化测试与监控：在生产规模扩展时，系统的复杂性和负载增加会带来更多的不确定性。通过自动化测试，生产系统可以在每次更新前进行回归测试和性能测试，确保系统在发布新功能时不会出现性能瓶颈或不可预见的错误。同时，通过监控工具（如Prometheus、Grafana），可以实时监控生产系统的性能指标，提前发现并解决潜在的性能问题。
自动化扩展与容灾能力：通过基础设施自动化（如 Terraform、Ansible），生产系统在面对突发流量时可以自动扩展资源，并在发生故障时进行自动化恢复。这种技术规模中的自动化能力，是生产系统在高负载或故障环境下能够保持高可用性的关键。
蓝绿部署和金丝雀发布：在大规模生产环境下，通过蓝绿部署和金丝雀发布，可以减小新功能或修复补丁上线时的风险，确保在问题发生时能够快速回滚。其实就是灰度发布，或者说要严格地执行灰度发布。

自动化能力不仅提高了生产系统的运维效率，还在生产规模扩展时提供了韧性和容错能力。

2.1.4 技术债务管理与可维护性

随着生产规模的扩展，技术债务的管理变得尤为重要。技术债务的管理不当会直接影响生产系统的性能和稳定性。技术规模中的技术债务管理策略需要融入生产规模的规划中，以确保系统在扩展过程中不会因为技术债务的积累而出现故障或性能下降。

定期重构与优化：随着系统的不断扩展，代码复杂度和技术债务不可避免地会增加。通过定期的代码重构和性能优化，可以减少技术债务的积累，确保系统在生产环境中的稳定性。例如，定期优化数据库查询或重构基础代码模块，可以避免随着业务增长而出现的性能瓶颈。
技术债务的监控与清理：通过技术债务监控工具，团队可以定期评估系统中的技术债务，并规划技术债务的偿还时间。特别是在生产系统扩展时，及时清理技术债务能够大幅减少系统的不可预测性，确保生产系统的可维护性。

更多技术债务的内容可以参考之前写的这篇文章：架构师必备：技术债务的识别、管理与解决之道

2.2 管理开发规模

开发规模指的是随着项目复杂度、代码库、开发团队人数的增加，如何有效管理开发流程、代码库和团队协作。包括以下几个部分：

2.2.1 代码库与模块化管理

随着项目的规模扩大，代码库的复杂度也随之增加。为了保持代码库的可维护性和可扩展性，合理的技术架构设计和技术栈选型至关重要。

模块化与组件化：模块化设计（例如微服务架构）能帮助团队将系统拆分为多个独立的模块或服务，减少耦合性，并允许团队并行开发。合理的模块化设计不仅可以简化代码管理，还能减少不同团队之间的依赖，提升开发效率。
技术栈的扩展性：技术栈的选择对开发规模的扩展至关重要。选用成熟、可扩展的技术栈（如Kubernetes、容器化、云原生技术）可以帮助团队更好地应对复杂的开发需求。技术栈选型不仅影响系统的运行能力，还影响团队的学习曲线、代码质量和开发速度。
接口设计与抽象：合理的接口抽象能够减少模块之间的依赖。通过面向接口编程，团队可以在不破坏项目整体架构的情况下，灵活地扩展或替换某些模块。这种设计使得开发团队在面对复杂业务时，能够保持系统的灵活性和可维护性。

2.2.2 开发流程与自动化

随着团队人数的增加和代码库的扩展，开发流程的复杂性也随之增加。为了提升开发效率，技术规模中的基础设施扩展性和自动化能力是开发流程中的重要组成部分。

持续集成与持续交付 (CI/CD) ：自动化工具链是开发规模扩展中的关键要素。通过自动化测试、构建、部署流程，开发团队能够更频繁地发布代码，减少人为操作的风险。技术规模中的自动化工具（如Jenkins、GitLab CI、CircleCI，各公有云的云效产品）对开发效率的提升至关重要。
代码评审与规范：制定统一的代码规范，确保团队成员的代码风格一致，避免“代码腐化”为难以维护的“意大利面条式代码”。通过代码评审（Code Review），团队可以发现潜在问题，提升代码的整体质量和可维护性。
自动化测试：技术规模扩展中的自动化程度直接影响开发团队的效率。通过引入单元测试、集成测试、端到端测试，团队可以在不断扩展的代码库中保持代码质量，并快速识别回归错误。
技术债务管理与重构计划：随着开发规模的扩大，技术债务的管理变得尤为重要。技术债务的积累会降低开发效率，增加维护成本。因此，定期的技术债务清理和代码重构计划是开发流程管理中的必要步骤。通过技术规模中的架构优化和代码重构，团队可以确保系统在业务增长时依然保持可维护性。

2.2.3 团队协作与知识管理

开发规模不仅仅依赖于技术架构和工具链的管理，还需要通过良好的协作机制和知识管理确保团队的高效运作。技术规模中的技术栈选型和架构设计也会影响团队的协作方式。

知识共享与文档化：在开发规模扩展的过程中，技术栈的复杂性增加，团队成员需要通过高效的知识管理平台（如Confluence、Notion）来共享与管理技术文档。特别是当团队采用复杂的技术架构时（如微服务或分布式架构），通过文档化来规范开发流程和技术决策，可以减少沟通成本，提升协作效率。
技术栈选择对协作的影响：选择合适的技术栈不仅影响系统的技术规模，也会影响团队的协作方式。例如，采用微服务架构可以让不同团队独立开发、部署自己的服务，减少团队之间的依赖。而采用更紧耦合的单体架构则需要更多的沟通与协调。因此，技术栈的选择在开发规模扩展中起到至关重要的作用。

2.2.4 选择合适的开发模型

开发模型是帮助团队组织开发流程、管理代码质量和发布节奏的框架。在不同的开发规模下，开发模型需要根据技术规模中涉及的技术栈、架构设计和自动化能力进行调整。

在开发规模扩展的过程中，技术栈和架构设计往往决定了开发模型的选择。例如：

微服务架构与敏捷开发模型：微服务架构鼓励独立发布和独立开发，因此更适合敏捷开发模式。在这种模式下，技术团队可以迭代地发布小的功能模块，并通过自动化测试和持续集成工具确保代码质量。微服务架构的技术规模管理要求开发模型灵活且高效，以适应快速变化的业务需求。
单体架构与瀑布模型：对于采用单体架构的系统，开发模型往往倾向于传统的瀑布模型或迭代开发模型。由于单体架构的耦合性较强，系统的发布和开发需要更为慎重，开发模型在这种情况下会更注重前期设计、集成测试和代码审核。

3 小结

管理规模的扩展不仅仅是对技术的挑战，更是对一个企业工程化与系统化能力的考验。通过清晰的架构设计、自动化工具的引入、规范化的流程和有效的团队协作机制，企业可以在规模扩张的同时保持研发效能和系统的稳定性。

这不仅要求架构师从技术角度进行弹性设计，还需要研发管理者从整体角度系统化地规划团队协作和流程优化。规模扩展的成功，依赖于工具、流程、架构和团队的有机结合与协同运作。只有通过持续的工程化改进和系统化的管理方法，企业才能在面对规模扩展时从容应对，并建立起长久的竞争优势。

规模的扩展并不可怕，真正的挑战在于能否通过合理的手段，保证系统和团队在快速变化的环境中依然具备强大而灵活的应对能力。

正如一座高楼，只有在扎实的地基之上，才能随风而屹立不倒。在研发管理的世界里，规模的管理就是那座高楼的地基。通过科学的规模管理，企业不仅能够应对当前的增长，更能够为未来的持续创新打下坚实的基础。

最后再次推荐一下 cursor 编辑器，写起来代码来真的很 6。

以上。