一、LLM重塑架构治理项的权重

随着cursor、trae等LLM IDE被程序员广泛使用，LLM承担了程序员的编程成本，而架构治理中目标为降低研发成本的治理项可能变得不再重要和必要。例如函数的认知复杂度，LLM能理解远超人类的上下文，可以快速理解函数的含义，甚至可以完成简单的需求开发。这时如果忽略LLM带来的变化，不调整治理项权重，那么必然会导致资源错位，沉没更多的机会成本。

除了对已有的治理项需要调低治理权重。LLM的应用可能会带来新的问题，这类问题可抽象的定义为基于模式生成代码的可用性问题。例如在使用LLM进行已有代码重构时出现的一些列badcase，见下表。这些问题随着LLM的应用，问题出现频次会在数量规模上放大，变成一个棘手的大问题。

在经历了架构治理的多个项目，有顺利达成预期的（如废弃代码治理），也有不太符合预期的（如问题函数的存量/增量治理、服务耦合治理）。通过对比这两种情况，以及对不符合预期项目的实际case的分析、研发的反馈、指标数据分析，本文尝试分析研发收到治理任务时的心理，来理解研发做出决策的关键因素有哪些，给后续的治理任务提供更多信息。

以下分为两种场景进行讨论，一是治理不符合预期的任务，研发多采取延宕治理策略。二是治理符合预期的任务，研发采取协助治理的策略。

一、延宕治理场景

Created At: 2025/06/27

旧的假设

这个文档也算是2025Q2针对问题函数治理的CI卡点方案的复盘。CI卡点方案开发了近一个季度，目前在3个试点业务线进行了启用，但是卡点数据不符合预期。具体而言是卡点的跳过率高达90%，且有业务线因业务迭代压力大把卡点又禁用了。

一、指标建设阶段

1）资源有限，项目周期长

分析问题的重要性

分析问题是发现问题和制定解决方案之间的步骤，是两者必不可少的衔接。这个必不可少体现在两个方面：一是这个分析问题的步骤必不可少，二是分析问题的时间必不可少。换句话来说，分析问题是确保”做正确的事”，制定解决方案则是”正确的做事”。

人们面对一个问题，容易出于本能反应，第一时间在脑子里形成一个解决方案，并告诉大脑这个问题是自明的、结论是清晰的，以此来避免理性脑的参与。另外，即便被外部规章约束需要去分析问题，往往在思想上不会重视，只会花很少的时间，得出一个主观的、片面的、偏差的结论，然后快速进入到执行阶段。

一、治理的必要性

代码和服务是需求的实体化表现，是由研发活动的产物。需求的变化和研发活动的复杂性决定了软件熵增的事实。治理动作是减熵的过程，目的是为了在更长期的范围维持需求的迭代效率。
例如，有些需求是偏定制的，则必然给代码引入新的判断逻辑，提高其复杂度；有些功能已经废弃了，其逻辑在代码却并未被删除；需求的变化，也导致代码逻辑的不连贯，理解和修改成本高；从人的角度来看，人员的变动、经验的不同、开发习惯不同、团队文化不同、组织奖惩机制不同都会在代码中引入更多的复杂度。另外，研发人员依赖的工具，如CI/CD、基础组件、自动化平台工具等都会反向影响编码行为。

合理设定项目目标

厘清项目目标很关键，付出劳动后如果预设目标不合理，那么会导致低估或否定劳动价值。在了解什么是一个好目标之前，先看以下几个真实的例子：

A项目：在做的事情是解决服务部署耗时长、不稳定的问题。一个好的目标是服务部署耗时TPxx下降，部署耗时方差变小；一个错误的目标是提高需求吞吐率、需求周期。

关于信息同步

把自己变透明，减少信息差

公司内的项目已经变得足够复杂，一个研发很难仅凭个人经验顺利的按期完成任务。把自己变得透明，可以减少信息差，这不会让你丧失项目的掌控感，而是会带来更多的好处，例如：1）获取更多角色视角的信息输入，越多的信息，能带来更全局的解题思路；2）给项目带来更多的评审者，使项目方案逻辑更完备，减小项目落地执行的风险；3）向上及时高频同步足够信息，让上层决策者对项目进度和走向更清晰，项目走偏时能第一时间被发现。每次信息同步，都是向上对齐，避免项目路径风险；5）项目计划的同步，能让项目的执行者和参与者明确要执行事项，更好的评定任务优先级和进行进度把控；6）能带来潜在的合作伙伴和用户，信息的输出能让用户更好的发现你和了解你在做什么。

务实做规划，使其可执行

上次在做23年下半年方向规划时，当时考虑到是新成立方向，所以规划内容偏形而上的概念性阐述，无法让团队同学对下半年要做的事情具象化，总体看来优先务虚。例如，描述了宏大的愿景，讲述了一堆我想做什么、以后要做成什么样，时间跨度大，不确定性强，很多事情没有经过严格论证就定了目标；反而对半年内要做的事项粗略带过，没有明确论述。总体而言，当时写的初版规划偏愿景，而非可执行的规划。

为什么规划