1. 这期周刊到底在聊什么先说清楚这不是一篇翻译稿也不是简单的链接罗列。Github周刊2026W37这一期我翻来覆去看了三遍最大的感受是它把当下开发者圈子里几个看似不搭界的热点用一条暗线串起来了——如何用更少的认知负荷换取更高的产出效率。这条暗线下面挂着五个东西ADHD输出技能、架构图校验渲染、懒开发少写代码、上下文省98%、规格驱动开发。你单看每一个好像都是独立的小工具或者小技巧但把它们放在一起你会发现它们都在解决同一个问题人的注意力是稀缺资源代码和文档的复杂度却在无限膨胀怎么让两者之间的摩擦降到最低。我先把结论摆在这儿这期周刊适合三类人看。第一类是每天被需求文档、架构图、代码评审三头拉扯的一线开发者第二类是在团队里负责技术方案落地、需要把模糊需求翻译成可执行规格的Tech Lead第三类是对AI辅助开发有实际使用经验、但总觉得差点意思的工程师。如果你只是听说过这些词但没动手试过那这篇内容会帮你省下至少两周的试错时间。为什么这么说因为我自己就是踩过坑的人。去年我尝试用纯自然语言驱动一个中型项目的开发结果上下文窗口爆了三次架构图和代码对不上最后返工的成本比从头写还高。这期周刊里提到的几个思路恰好是我后来摸索出来的那套方法的理论版和工具版。所以下面我不打算照本宣科而是结合我自己的实操经验把这五个点拆开揉碎讲清楚它们各自解决什么问题、怎么配合使用、以及哪些地方容易翻车。2. ADHD输出技能不是让你更专注而是让产出更抗打断2.1 为什么输出技能要跟ADHD挂钩第一次看到ADHD输出技能这个词我以为是某种注意力训练方法。后来才明白它指的是一套专门为容易分心、频繁被打断的人设计的输出工作流。注意这里的关键词是输出不是输入。传统的时间管理方法都在教你如何集中注意力去阅读、去思考但ADHD人群的痛点往往不在输入端而在输出端——脑子里想了很多手上就是落不了地或者做到一半被叫走回来就接不上了。这个技能的核心逻辑是把输出过程切成足够小的块每一块都能在5到10分钟内完成并且每一块的完成状态都是可保存、可恢复的。听起来很简单对吧但真正做起来需要你在工具链和习惯两个层面同时改造。我自己的做法是把任何一个开发任务拆成原子提交级别。比如要实现一个用户登录接口我不会写一个完成登录功能的大任务而是拆成定义请求参数结构、写参数校验逻辑、写数据库查询、写密码比对、写token生成、写错误返回。每一步做完就提交一次哪怕代码还不完整哪怕测试还没写。这样做的好处是即使我中途被拉去开一个小时的会回来之后打开git log我能立刻知道上次做到哪了下一步该干什么。2.2 具体怎么落地从任务拆分到工具配置落地这套方法我总结了一个三刀切原则。第一刀按可验证的最小单元切。什么叫可验证就是你做完这一步能有一个明确的方式判断它对不对。比如写参数校验逻辑这一步验证方式就是传一个空参数进去看它是否返回预期的错误码。不要切出优化代码结构这种没法验证的步骤。第二刀按上下文依赖切。如果两个步骤之间需要共享大量变量或状态那它们应该放在同一个块里。比如查询数据库和处理查询结果通常要一起做因为中间的数据结构是连贯的。但生成token和写日志就可以分开因为它们之间没有强依赖。第三刀按中断恢复成本切。有些步骤被打断后恢复成本极高比如正在调试一个复杂的并发问题这时候如果被叫走回来可能完全忘了当时的思路。这种步骤要么安排在不容易被打扰的时间段要么在开始前先写下当前假设和下一步验证动作作为恢复时的锚点。工具层面我用的是最朴素的组合一个看板工具加一个命令行别名。看板上只有三列待拆解、进行中、已完成。每个任务卡片上必须写清楚完成标准是什么。命令行别名则是用来快速提交的比如我配置了一个wip命令自动执行git add -A git commit -m wip: 当前步骤描述省去每次提交时思考commit message的时间。注意原子提交不意味着可以提交烂代码到主分支。我的做法是在个人分支上随便提交等一个功能模块完整了再用交互式rebase整理成干净的提交记录合并回去。这样既保证了中断恢复的便利又不污染团队的历史。2.3 实操心得哪些坑我替你踩过了第一个坑是拆得太碎。我一开始把任务拆到写一个if语句这种级别结果一天提交了四十多次git log乱得没法看而且频繁切换上下文反而更累。后来我找到一个经验值每个原子任务的完成时间在5到15分钟之间比较合适低于5分钟说明拆过头了高于15分钟说明还可以再切。第二个坑是忽略环境准备。ADHD人群特别容易在准备工作上卡住比如要写代码了发现依赖没装、数据库没启动、测试数据没准备。这些准备工作本身也是任务应该被显式地列出来并提前完成。我现在习惯在每天结束前把第二天要用的环境和数据都准备好这样第二天坐下来就能直接进入输出状态。第三个坑是没有中断记录。被叫走的时候如果只是关掉编辑器就走回来大概率要花十分钟重新进入状态。我的做法是强制自己花30秒写一行注释格式是// WIP: 当前在做什么 | 下一步要做什么 | 已知问题。这行注释不提交就留在编辑器里回来一眼就能接上。3. 架构图校验渲染让图和代码不再各说各话3.1 架构图为什么需要校验架构图这个东西画的时候都觉得自己画得挺清楚过两个月再看发现跟代码完全对不上。更麻烦的是团队里每个人脑子里的架构图都不一样开会的时候对着同一张图能吵起来。根本原因在于架构图是手工维护的而代码是自动演进的两者之间没有强制的一致性约束。架构图校验渲染这个思路核心就是给架构图加上一层校验机制。具体来说就是把架构图用某种结构化格式描述出来然后用工具去检查这个描述跟实际代码结构是否一致最后再渲染成可视化的图。这样图不再是画出来的而是生成出来的代码变了图就跟着变不一致的地方会被工具标出来。我试过几种方案目前比较顺手的是用代码即架构描述的方式。比如用Python或者YAML定义一个服务列表、每个服务的依赖关系、数据流向然后写一个脚本去扫描代码仓库里的实际依赖做对比。对比结果用颜色标注绿色表示一致黄色表示图里有但代码里没有红色表示代码里有但图里没有。3.2 从Excel到Visio再到自动生成一条演进路径热搜词里有个visio根据excel文件生成组织架构图这个需求其实很典型。很多团队的组织架构图或者系统架构图最初都是在Excel里维护一份列表然后手工在Visio里画。每次人员变动或者系统调整就要重新画一遍费时费力还容易漏。我的建议是分三步走。第一步先把Excel里的数据结构化至少要有节点名称、节点类型、上级节点、备注这几列。第二步写一个简单的脚本读Excel生成Graphviz或者Mermaid格式的描述文件。第三步把生成过程集成到CI里每次Excel更新就自动重新生成图。这里有个细节要注意不要试图一步到位做全自动。我见过有团队想直接从代码里反向生成完整的架构图结果因为代码里的依赖关系太细碎生成的图跟蜘蛛网一样没法看。正确的做法是人工维护一份逻辑架构的描述然后用工具去校验它跟物理实现之间的偏差而不是让工具去猜你的逻辑架构。3.3 校验规则怎么定三个层次的检查架构图校验不是简单的字符串比对需要分层次设计规则。第一层是存在性检查。图里画了一个服务代码里有没有对应的模块代码里有一个数据库表图里有没有体现这一层最简单也最容易发现明显的遗漏。第二层是关系性检查。图里说服务A调用服务B代码里有没有对应的HTTP客户端或者RPC调用图里说数据从队列流向处理器代码里有没有对应的消费者这一层需要解析代码的依赖关系稍微复杂一些但价值最大因为依赖关系出错往往导致线上故障。第三层是约束性检查。比如团队规定不允许跨层直接调用数据库那就要检查代码里有没有违反这个约束的地方。这一层需要自定义规则适合用策略模式来实现每条规则一个检查器。提示校验规则不要一次性写太多先从存在性检查开始跑通了再逐步加关系性和约束性检查。我一开始写了二十多条规则结果误报太多团队直接把这个工具弃用了。后来精简到五条核心规则准确率上来了大家才愿意用。3.4 渲染输出的实用技巧渲染这块我踩过的最大坑是图太复杂。一张图里塞了五十个节点、上百条连线没人看得清。后来我学乖了渲染的时候支持分层过滤默认只显示核心服务需要看细节的时候再展开某个子系统。实现方式就是在节点上打标签渲染脚本根据标签决定是否显示。另一个技巧是用颜色和线型表达状态。比如实线表示同步调用虚线表示异步消息红色表示已废弃但还在运行的依赖灰色表示计划中但还没实现的模块。这样一张图不仅能看结构还能看演进方向。还有一点渲染出来的图最好能自动嵌入到文档或者README里。我用的是在CI里生成SVG然后自动提交到文档仓库的指定目录。这样每次代码合并文档里的图就自动更新了不需要人工干预。4. 懒开发少写代码不是偷懒是精准用力4.1 懒开发的真正含义懒开发这个词容易被误解成能不做就不做。但在我理解的语境里它的意思是把精力花在真正独特、真正有业务价值的地方其他一切能复用就复用能自动就自动能删就删。这个理念其实不新鲜DRY原则说了几十年了。但为什么现在又被拿出来说因为AI辅助编程的普及让少写代码有了新的实现路径。以前你要复用代码得自己去找库、读文档、适配接口。现在你可以让AI帮你生成适配层甚至直接让AI根据你的业务逻辑生成定制化的实现你只需要审查和调整。我自己的实践是在动手写任何一行代码之前先问三个问题这个问题有没有现成的库能解决这个逻辑能不能用配置代替代码这段代码如果删掉系统还能不能跑三个问题问完通常能砍掉30%到50%的代码量。4.2 三个层次的少写第一个层次是用库代替自研。这个道理大家都懂但实际操作中很多人会因为库的接口不完全是我想的那样而选择自己写。我的经验是只要库的核心功能覆盖了80%的需求剩下的20%用适配层或者包装层解决总体成本仍然低于自研。因为自研的代码需要维护、需要测试、需要文档这些隐性成本往往被低估。第二个层次是用配置代替逻辑。很多业务规则本质上是一张决策表比如不同用户等级对应不同的折扣率。这种逻辑如果写成if-else代码会越来越长。更好的做法是把规则抽出来放到配置文件或者数据库里代码只负责读取规则并执行。这样产品经理改规则不需要找开发开发也不需要为了改一个数字而发版。第三个层次是用生成代替手写。这个层次门槛稍高但收益也最大。比如CRUD接口、数据模型类、API客户端这些代码结构高度重复完全可以用代码生成器来产出。我现在的做法是用模板加元数据的方式定义一次数据模型自动生成后端的实体类、前端的TypeScript类型、API文档、甚至单元测试的骨架。4.3 实操案例一个接口从80行砍到12行举个具体的例子。我之前写过一个查询用户订单列表的接口最初的实现大概80行包括参数校验、权限检查、分页处理、数据库查询、结果转换、异常处理。后来我做了三步改造。第一步参数校验和权限检查用装饰器统一处理接口函数里不再出现这些代码。第二步分页和数据库查询用ORM的通用方法封装传入查询条件即可。第三步结果转换用序列化器自动完成不需要手写字段映射。改造之后接口函数只剩下12行核心逻辑一目了然。这12行代码里真正跟用户订单这个业务相关的其实只有查询条件的构造和排序规则。其他都是通用逻辑被抽到了框架层。这样做的好处是当我需要写第二个、第三个类似接口的时候只需要关注业务差异部分开发速度提升了三倍以上。注意抽象是有成本的。如果某个逻辑只在一个地方用不要急着抽象。我见过有团队为了复用把简单的代码抽成了三层继承结果改一个字段要跳五个文件。判断标准很简单同样的逻辑出现第三次的时候再考虑抽象。4.4 懒开发的边界在哪里懒开发不是无底线地减少代码。有些代码是不能省的比如错误处理、日志记录、安全校验。这些代码看起来不产生业务价值但它们是系统稳定运行的保障。我的原则是业务逻辑能省则省非业务逻辑该写就写。另外懒开发也不意味着不写测试。恰恰相反代码越少测试越重要。因为每一行代码都承载了更多的逻辑密度一旦出错影响面更大。我的做法是对于自动生成的代码依赖生成器的测试对于手写的核心逻辑测试覆盖率要求达到90%以上。还有一个边界是可读性。有些聪明的写法确实能减少代码行数但会让后来的人看不懂。比如用一行lambda表达式替代十行循环行数少了但调试的时候堆栈信息完全没法看。我的经验是代码行数减少的前提是可读性不降低如果两者冲突优先保可读性。5. 上下文省98%大模型辅助开发的关键瓶颈5.1 上下文为什么这么贵用过AI辅助编程的人都有体会模型的能力很强但上下文窗口是硬约束。你把整个代码仓库塞进去它处理不过来你只塞一个文件它又缺乏全局视野。更麻烦的是上下文越长模型的注意力越分散输出质量反而下降。上下文省98%这个说法我理解它的核心意思是通过精准的上下文管理只把真正相关的信息喂给模型从而在有限的窗口里获得更好的输出。这跟热搜词里的上下文工程、提示词工程与上下文工程是同一个方向。我自己的测算数据是一个中型项目如果无差别地把所有相关文件都塞给模型一次对话的token消耗大概在5万到8万。经过上下文优化之后同样的任务token消耗可以降到1000到2000节省比例确实在95%以上。节省的不仅是成本更重要的是响应速度和输出质量。5.2 上下文筛选的四个维度怎么判断哪些上下文是真正相关的我总结四个维度。第一个维度是调用链相关。如果我要修改一个函数那么调用这个函数的代码、这个函数调用的代码是强相关的。其他不在这条链上的代码大概率不需要。第二个维度是数据流相关。如果我要修改一个数据结构那么所有使用这个结构的序列化、反序列化、校验逻辑都是相关的。这个维度比调用链更隐蔽但往往更重要因为数据结构的变化影响面更广。第三个维度是变更历史相关。如果某个文件最近频繁修改或者跟当前任务在同一个feature分支上有改动那它相关的概率更高。这个维度可以用git log来辅助判断。第四个维度是语义相关。有些代码在调用链和数据流上都不相关但在业务语义上相关。比如我要实现一个退款功能那么支付相关的代码虽然不直接调用但业务逻辑上是紧密关联的。这个维度需要靠人的判断或者用向量检索来辅助。5.3 实操我是怎么把上下文从8万降到1500的具体操作上我有一套固定的流程。第一步明确任务边界。在跟模型对话之前我先用一句话写清楚我要做什么。比如给用户订单接口增加按时间范围筛选的功能。这句话本身就是最好的上下文筛选器跟这个任务无关的代码一律不考虑。第二步用工具提取相关文件。我写了一个脚本输入是一个函数名或者文件名输出是调用链上下游的文件列表。这个脚本基于静态分析准确率大概在80%左右剩下的20%靠人工补充。第三步压缩文件内容。相关文件找到之后不是整个文件塞进去而是只提取相关的函数、类、接口定义。比如一个500行的文件可能只有30行跟当前任务相关那就只取这30行。压缩的时候保留函数签名和关键注释去掉实现细节。第四步维护一个上下文缓存。同一个任务往往会进行多轮对话每轮都重新提取上下文太浪费。我的做法是把提取好的上下文存到一个临时文件里每轮对话时按需加载。如果任务变了再重新提取。提示上下文压缩的时候一定要保留类型定义和接口签名。我吃过亏只保留了函数体结果模型生成的代码调用了一个不存在的参数因为签名被我省掉了。5.4 上下文工程的常见误区第一个误区是上下文越多越好。很多人觉得给模型的信息越多它越能理解我的意图。实际上恰恰相反无关信息会干扰模型的判断。我做过对比实验同一个任务给模型3个相关文件比给10个文件其中7个不相关的输出质量高出一大截。第二个误区是忽略上下文的顺序。模型对上下文的开头和结尾更敏感中间部分容易被忽略。所以重要的信息要放在开头或者结尾比如任务描述放在最前面关键约束放在最后面。第三个误区是不做上下文清理。多轮对话之后上下文里积累了大量历史信息其中很多已经过时了。比如前面讨论了一个方案后面又否决了但否决的信息还在上下文里模型可能会混淆。我的做法是每当方案确定或者方向调整时主动清理掉过时的上下文重新开始一轮对话。第四个误区是把上下文工程当成一次性工作。上下文需求是随着任务推进而变化的。开始的时候可能需要全局视野深入之后只需要局部细节。所以上下文管理是一个持续的过程不是配置一次就完事了。6. 规格驱动开发从写代码到写规格6.1 规格驱动开发解决什么问题规格驱动开发这个概念我最早是在硬件设计领域看到的。芯片设计先写规格文档然后根据规格生成验证用例最后再实现电路。软件领域借鉴这个思路核心是先把要做什么用结构化、可验证的方式描述清楚然后再让代码去实现这个描述。它解决的核心问题是需求在传递过程中失真。产品经理说用户要能快速找到商品开发理解成加一个搜索框测试理解成搜索框能输入文字最后上线发现用户想要的是按图片搜索。规格驱动开发要求把快速找到商品翻译成明确的、可验证的规格比如用户输入关键词后系统在500毫秒内返回匹配的商品列表匹配规则包括名称模糊匹配和分类精确匹配。这个规格一旦确定代码实现、测试用例、验收标准都围绕它展开减少理解偏差。6.2 规格怎么写结构化的三个要素我实践下来一份好的规格至少包含三个要素。第一个要素是输入输出定义。输入是什么类型、什么范围、什么格式输出是什么结构、什么精度、什么错误码。这部分要精确到可以直接生成接口定义的程度。第二个要素是行为描述。在什么条件下触发什么动作条件之间的优先级是什么异常情况怎么处理。这部分最好用决策表或者状态机来描述比自然语言更不容易产生歧义。第三个要素是验收标准。怎么判断这个规格被正确实现了通常是一组测试用例包括正常路径、边界条件、异常路径。这些用例可以直接作为自动化测试的输入。我现在的习惯是在写任何实现代码之前先用YAML或者类似的结构化格式把规格写出来。写规格的过程本身就能发现很多需求上的模糊点。经常出现的情况是写到一半发现某个条件没定义清楚这时候去找产品经理确认比写完代码再返工成本低得多。6.3 从规格到代码自动化能走多远规格写完之后能自动生成代码吗我的经验是部分可以但不能全自动。可以自动生成的部分包括接口定义、数据模型、参数校验逻辑、基础的CRUD操作、单元测试骨架。这些部分结构固定从规格到代码的映射关系明确用模板引擎就能搞定。不能自动生成的部分包括复杂的业务逻辑、性能优化、异常恢复策略、与其他系统的集成。这些部分需要人的判断和经验规格只能描述做什么没法描述怎么做。我的做法是用规格生成代码骨架然后人工填充核心逻辑。这样既保证了接口和数据结构的一致性又保留了人工判断的空间。生成的部分大概占60%人工写的占40%总体效率比纯手写提升一倍以上。6.4 规格驱动开发的团队落地经验在团队里推行规格驱动开发最大的阻力不是技术而是习惯。开发同学习惯了拿到需求就写代码觉得写规格是额外负担。我的经验是不要一上来就要求全团队执行先在一个小项目上试点用数据说话。我们试点项目的对比数据是写规格花了2天实现花了3天测试花了1天总共6天。对照项目没写规格实现花了4天测试花了3天因为反复发现理解偏差总共7天。而且试点项目的线上bug数量是对照组的三分之一。数据摆出来之后团队的接受度明显提高。另一个经验是规格的粒度要适中。太粗了起不到约束作用太细了写规格的时间比写代码还长。我的建议是规格描述到接口级别就够了不需要描述到函数内部实现。比如描述查询订单接口接受时间范围参数返回订单列表不需要描述用二分查找定位时间范围。注意规格是需要维护的。代码改了规格没改规格就失去了权威性慢慢就没人看了。我的做法是把规格文件跟代码放在同一个仓库代码评审的时候同时检查规格是否更新。CI里也加一个检查如果代码的接口签名变了但规格没变就报错。7. 这五个东西怎么配合使用单独看这五个点每个都有价值。但真正有意思的是把它们串起来用。我的工作流是这样的接到一个需求先用规格驱动开发的方式把需求翻译成结构化规格。写规格的过程中用上下文省98%的思路只提取跟这个需求相关的代码和文档作为参考。规格确定后用懒开发的原则评估哪些部分能用现成的库哪些部分能自动生成哪些部分必须手写。然后按照ADHD输出技能的方法把实现任务拆成原子级别逐个完成。最后用架构图校验渲染来验证实现是否符合预期的架构约束。这套流程跑下来我的体感是前期花在规格和上下文准备上的时间多了但后期返工和调试的时间大幅减少。总体效率提升大概在40%左右而且心理负担轻了很多因为每一步都有明确的完成标准和恢复点。当然这套方法不是银弹。它更适合中等规模以上的项目对于一次性脚本或者原型验证反而显得笨重。另外它对团队协作的要求比较高如果只有你一个人用这套方法而其他人还是老样子效果会打折扣。8. 几个我踩过的坑和对应的解法第一个坑是工具链太复杂。我一开始想把每个环节都用最好的工具结果光是配置工具就花了一周真正干活的时间反而少了。后来我精简到只保留三个核心工具一个看板、一个代码生成脚本、一个上下文提取脚本。其他环节能用命令行就用命令行能用现成工具就用现成工具。第二个坑是规格写得太完美。我有一次花了两天写规格把每个边界条件都考虑到了结果实现的时候发现需求变了规格全部作废。后来我调整策略规格写到80%的把握就动手剩下的20%在实现过程中补充。规格是活的文档不是一次性的合同。第三个坑是上下文压缩过度。有一次为了省token我把上下文压得太狠结果模型生成的代码引用了一个不存在的工具类。后来我定了一个底线类型定义、接口签名、关键配置这三类信息无论多长都不压缩。第四个坑是架构图校验规则太严。我一开始设了二十多条规则每次提交都报一堆警告团队很快就烦了。后来我把规则分成阻断和提醒两级只有严重的不一致才阻断合并其他的只提醒不拦截。这样既保证了关键约束又不会造成太多噪音。第五个坑是原子提交太碎。前面提过我一开始把任务拆得太细一天提交几十次git历史乱得没法看。后来我定了一个规则每个原子提交必须对应一个可验证的完成状态如果两个提交之间没有可验证的差异就合并成一个。9. 最后分享几个实用的小技巧关于上下文管理我还有一个技巧给常用的代码片段打标签。比如用户认证、数据库连接、错误处理这些高频出现的逻辑我提前整理成标准片段需要的时候直接引用标签而不是每次都去搜索文件。这样既节省了提取时间又保证了上下文的一致性。关于规格驱动开发我建议从接口规格开始不要一上来就搞全系统规格。选一个最近要做的接口用结构化的方式把输入输出、行为、验收标准写清楚然后走一遍完整流程。跑通一个之后再推广到其他接口。关于架构图校验我的经验是先从服务依赖图开始。因为服务之间的依赖关系最容易出错也最容易导致线上故障。把服务依赖校验跑通了再逐步扩展到数据流和部署架构。关于懒开发我有一个判断标准如果一段代码我写了三遍以上那它就应该被抽象或者生成。如果只写了一遍哪怕看起来有点重复也先放着等出现第三次的时候再处理。关于ADHD输出技能最重要的一点是接受自己会被打断。不要试图创造一个完全不被打扰的环境那不现实。而是假设随时会被打断然后围绕这个假设来设计工作流。这样心态上会轻松很多效率反而更高。这套方法我用了大概半年最大的感受是开发这件事写代码本身占的时间其实不多更多的时间花在理解需求、设计方案、调试问题上。把后面这些环节的效率提上来比单纯追求敲代码的速度有意义得多。
1. 这期周刊到底在聊什么先说清楚这不是一篇翻译稿也不是简单的链接罗列。Github周刊2026W37这一期我翻来覆去看了三遍最大的感受是它把当下开发者圈子里几个看似不搭界的热点用一条暗线串起来了——如何用更少的认知负荷换取更高的产出效率。这条暗线下面挂着五个东西ADHD输出技能、架构图校验渲染、懒开发少写代码、上下文省98%、规格驱动开发。你单看每一个好像都是独立的小工具或者小技巧但把它们放在一起你会发现它们都在解决同一个问题人的注意力是稀缺资源代码和文档的复杂度却在无限膨胀怎么让两者之间的摩擦降到最低。我先把结论摆在这儿这期周刊适合三类人看。第一类是每天被需求文档、架构图、代码评审三头拉扯的一线开发者第二类是在团队里负责技术方案落地、需要把模糊需求翻译成可执行规格的Tech Lead第三类是对AI辅助开发有实际使用经验、但总觉得差点意思的工程师。如果你只是听说过这些词但没动手试过那这篇内容会帮你省下至少两周的试错时间。为什么这么说因为我自己就是踩过坑的人。去年我尝试用纯自然语言驱动一个中型项目的开发结果上下文窗口爆了三次架构图和代码对不上最后返工的成本比从头写还高。这期周刊里提到的几个思路恰好是我后来摸索出来的那套方法的理论版和工具版。所以下面我不打算照本宣科而是结合我自己的实操经验把这五个点拆开揉碎讲清楚它们各自解决什么问题、怎么配合使用、以及哪些地方容易翻车。2. ADHD输出技能不是让你更专注而是让产出更抗打断2.1 为什么输出技能要跟ADHD挂钩第一次看到ADHD输出技能这个词我以为是某种注意力训练方法。后来才明白它指的是一套专门为容易分心、频繁被打断的人设计的输出工作流。注意这里的关键词是输出不是输入。传统的时间管理方法都在教你如何集中注意力去阅读、去思考但ADHD人群的痛点往往不在输入端而在输出端——脑子里想了很多手上就是落不了地或者做到一半被叫走回来就接不上了。这个技能的核心逻辑是把输出过程切成足够小的块每一块都能在5到10分钟内完成并且每一块的完成状态都是可保存、可恢复的。听起来很简单对吧但真正做起来需要你在工具链和习惯两个层面同时改造。我自己的做法是把任何一个开发任务拆成原子提交级别。比如要实现一个用户登录接口我不会写一个完成登录功能的大任务而是拆成定义请求参数结构、写参数校验逻辑、写数据库查询、写密码比对、写token生成、写错误返回。每一步做完就提交一次哪怕代码还不完整哪怕测试还没写。这样做的好处是即使我中途被拉去开一个小时的会回来之后打开git log我能立刻知道上次做到哪了下一步该干什么。2.2 具体怎么落地从任务拆分到工具配置落地这套方法我总结了一个三刀切原则。第一刀按可验证的最小单元切。什么叫可验证就是你做完这一步能有一个明确的方式判断它对不对。比如写参数校验逻辑这一步验证方式就是传一个空参数进去看它是否返回预期的错误码。不要切出优化代码结构这种没法验证的步骤。第二刀按上下文依赖切。如果两个步骤之间需要共享大量变量或状态那它们应该放在同一个块里。比如查询数据库和处理查询结果通常要一起做因为中间的数据结构是连贯的。但生成token和写日志就可以分开因为它们之间没有强依赖。第三刀按中断恢复成本切。有些步骤被打断后恢复成本极高比如正在调试一个复杂的并发问题这时候如果被叫走回来可能完全忘了当时的思路。这种步骤要么安排在不容易被打扰的时间段要么在开始前先写下当前假设和下一步验证动作作为恢复时的锚点。工具层面我用的是最朴素的组合一个看板工具加一个命令行别名。看板上只有三列待拆解、进行中、已完成。每个任务卡片上必须写清楚完成标准是什么。命令行别名则是用来快速提交的比如我配置了一个wip命令自动执行git add -A git commit -m wip: 当前步骤描述省去每次提交时思考commit message的时间。注意原子提交不意味着可以提交烂代码到主分支。我的做法是在个人分支上随便提交等一个功能模块完整了再用交互式rebase整理成干净的提交记录合并回去。这样既保证了中断恢复的便利又不污染团队的历史。2.3 实操心得哪些坑我替你踩过了第一个坑是拆得太碎。我一开始把任务拆到写一个if语句这种级别结果一天提交了四十多次git log乱得没法看而且频繁切换上下文反而更累。后来我找到一个经验值每个原子任务的完成时间在5到15分钟之间比较合适低于5分钟说明拆过头了高于15分钟说明还可以再切。第二个坑是忽略环境准备。ADHD人群特别容易在准备工作上卡住比如要写代码了发现依赖没装、数据库没启动、测试数据没准备。这些准备工作本身也是任务应该被显式地列出来并提前完成。我现在习惯在每天结束前把第二天要用的环境和数据都准备好这样第二天坐下来就能直接进入输出状态。第三个坑是没有中断记录。被叫走的时候如果只是关掉编辑器就走回来大概率要花十分钟重新进入状态。我的做法是强制自己花30秒写一行注释格式是// WIP: 当前在做什么 | 下一步要做什么 | 已知问题。这行注释不提交就留在编辑器里回来一眼就能接上。3. 架构图校验渲染让图和代码不再各说各话3.1 架构图为什么需要校验架构图这个东西画的时候都觉得自己画得挺清楚过两个月再看发现跟代码完全对不上。更麻烦的是团队里每个人脑子里的架构图都不一样开会的时候对着同一张图能吵起来。根本原因在于架构图是手工维护的而代码是自动演进的两者之间没有强制的一致性约束。架构图校验渲染这个思路核心就是给架构图加上一层校验机制。具体来说就是把架构图用某种结构化格式描述出来然后用工具去检查这个描述跟实际代码结构是否一致最后再渲染成可视化的图。这样图不再是画出来的而是生成出来的代码变了图就跟着变不一致的地方会被工具标出来。我试过几种方案目前比较顺手的是用代码即架构描述的方式。比如用Python或者YAML定义一个服务列表、每个服务的依赖关系、数据流向然后写一个脚本去扫描代码仓库里的实际依赖做对比。对比结果用颜色标注绿色表示一致黄色表示图里有但代码里没有红色表示代码里有但图里没有。3.2 从Excel到Visio再到自动生成一条演进路径热搜词里有个visio根据excel文件生成组织架构图这个需求其实很典型。很多团队的组织架构图或者系统架构图最初都是在Excel里维护一份列表然后手工在Visio里画。每次人员变动或者系统调整就要重新画一遍费时费力还容易漏。我的建议是分三步走。第一步先把Excel里的数据结构化至少要有节点名称、节点类型、上级节点、备注这几列。第二步写一个简单的脚本读Excel生成Graphviz或者Mermaid格式的描述文件。第三步把生成过程集成到CI里每次Excel更新就自动重新生成图。这里有个细节要注意不要试图一步到位做全自动。我见过有团队想直接从代码里反向生成完整的架构图结果因为代码里的依赖关系太细碎生成的图跟蜘蛛网一样没法看。正确的做法是人工维护一份逻辑架构的描述然后用工具去校验它跟物理实现之间的偏差而不是让工具去猜你的逻辑架构。3.3 校验规则怎么定三个层次的检查架构图校验不是简单的字符串比对需要分层次设计规则。第一层是存在性检查。图里画了一个服务代码里有没有对应的模块代码里有一个数据库表图里有没有体现这一层最简单也最容易发现明显的遗漏。第二层是关系性检查。图里说服务A调用服务B代码里有没有对应的HTTP客户端或者RPC调用图里说数据从队列流向处理器代码里有没有对应的消费者这一层需要解析代码的依赖关系稍微复杂一些但价值最大因为依赖关系出错往往导致线上故障。第三层是约束性检查。比如团队规定不允许跨层直接调用数据库那就要检查代码里有没有违反这个约束的地方。这一层需要自定义规则适合用策略模式来实现每条规则一个检查器。提示校验规则不要一次性写太多先从存在性检查开始跑通了再逐步加关系性和约束性检查。我一开始写了二十多条规则结果误报太多团队直接把这个工具弃用了。后来精简到五条核心规则准确率上来了大家才愿意用。3.4 渲染输出的实用技巧渲染这块我踩过的最大坑是图太复杂。一张图里塞了五十个节点、上百条连线没人看得清。后来我学乖了渲染的时候支持分层过滤默认只显示核心服务需要看细节的时候再展开某个子系统。实现方式就是在节点上打标签渲染脚本根据标签决定是否显示。另一个技巧是用颜色和线型表达状态。比如实线表示同步调用虚线表示异步消息红色表示已废弃但还在运行的依赖灰色表示计划中但还没实现的模块。这样一张图不仅能看结构还能看演进方向。还有一点渲染出来的图最好能自动嵌入到文档或者README里。我用的是在CI里生成SVG然后自动提交到文档仓库的指定目录。这样每次代码合并文档里的图就自动更新了不需要人工干预。4. 懒开发少写代码不是偷懒是精准用力4.1 懒开发的真正含义懒开发这个词容易被误解成能不做就不做。但在我理解的语境里它的意思是把精力花在真正独特、真正有业务价值的地方其他一切能复用就复用能自动就自动能删就删。这个理念其实不新鲜DRY原则说了几十年了。但为什么现在又被拿出来说因为AI辅助编程的普及让少写代码有了新的实现路径。以前你要复用代码得自己去找库、读文档、适配接口。现在你可以让AI帮你生成适配层甚至直接让AI根据你的业务逻辑生成定制化的实现你只需要审查和调整。我自己的实践是在动手写任何一行代码之前先问三个问题这个问题有没有现成的库能解决这个逻辑能不能用配置代替代码这段代码如果删掉系统还能不能跑三个问题问完通常能砍掉30%到50%的代码量。4.2 三个层次的少写第一个层次是用库代替自研。这个道理大家都懂但实际操作中很多人会因为库的接口不完全是我想的那样而选择自己写。我的经验是只要库的核心功能覆盖了80%的需求剩下的20%用适配层或者包装层解决总体成本仍然低于自研。因为自研的代码需要维护、需要测试、需要文档这些隐性成本往往被低估。第二个层次是用配置代替逻辑。很多业务规则本质上是一张决策表比如不同用户等级对应不同的折扣率。这种逻辑如果写成if-else代码会越来越长。更好的做法是把规则抽出来放到配置文件或者数据库里代码只负责读取规则并执行。这样产品经理改规则不需要找开发开发也不需要为了改一个数字而发版。第三个层次是用生成代替手写。这个层次门槛稍高但收益也最大。比如CRUD接口、数据模型类、API客户端这些代码结构高度重复完全可以用代码生成器来产出。我现在的做法是用模板加元数据的方式定义一次数据模型自动生成后端的实体类、前端的TypeScript类型、API文档、甚至单元测试的骨架。4.3 实操案例一个接口从80行砍到12行举个具体的例子。我之前写过一个查询用户订单列表的接口最初的实现大概80行包括参数校验、权限检查、分页处理、数据库查询、结果转换、异常处理。后来我做了三步改造。第一步参数校验和权限检查用装饰器统一处理接口函数里不再出现这些代码。第二步分页和数据库查询用ORM的通用方法封装传入查询条件即可。第三步结果转换用序列化器自动完成不需要手写字段映射。改造之后接口函数只剩下12行核心逻辑一目了然。这12行代码里真正跟用户订单这个业务相关的其实只有查询条件的构造和排序规则。其他都是通用逻辑被抽到了框架层。这样做的好处是当我需要写第二个、第三个类似接口的时候只需要关注业务差异部分开发速度提升了三倍以上。注意抽象是有成本的。如果某个逻辑只在一个地方用不要急着抽象。我见过有团队为了复用把简单的代码抽成了三层继承结果改一个字段要跳五个文件。判断标准很简单同样的逻辑出现第三次的时候再考虑抽象。4.4 懒开发的边界在哪里懒开发不是无底线地减少代码。有些代码是不能省的比如错误处理、日志记录、安全校验。这些代码看起来不产生业务价值但它们是系统稳定运行的保障。我的原则是业务逻辑能省则省非业务逻辑该写就写。另外懒开发也不意味着不写测试。恰恰相反代码越少测试越重要。因为每一行代码都承载了更多的逻辑密度一旦出错影响面更大。我的做法是对于自动生成的代码依赖生成器的测试对于手写的核心逻辑测试覆盖率要求达到90%以上。还有一个边界是可读性。有些聪明的写法确实能减少代码行数但会让后来的人看不懂。比如用一行lambda表达式替代十行循环行数少了但调试的时候堆栈信息完全没法看。我的经验是代码行数减少的前提是可读性不降低如果两者冲突优先保可读性。5. 上下文省98%大模型辅助开发的关键瓶颈5.1 上下文为什么这么贵用过AI辅助编程的人都有体会模型的能力很强但上下文窗口是硬约束。你把整个代码仓库塞进去它处理不过来你只塞一个文件它又缺乏全局视野。更麻烦的是上下文越长模型的注意力越分散输出质量反而下降。上下文省98%这个说法我理解它的核心意思是通过精准的上下文管理只把真正相关的信息喂给模型从而在有限的窗口里获得更好的输出。这跟热搜词里的上下文工程、提示词工程与上下文工程是同一个方向。我自己的测算数据是一个中型项目如果无差别地把所有相关文件都塞给模型一次对话的token消耗大概在5万到8万。经过上下文优化之后同样的任务token消耗可以降到1000到2000节省比例确实在95%以上。节省的不仅是成本更重要的是响应速度和输出质量。5.2 上下文筛选的四个维度怎么判断哪些上下文是真正相关的我总结四个维度。第一个维度是调用链相关。如果我要修改一个函数那么调用这个函数的代码、这个函数调用的代码是强相关的。其他不在这条链上的代码大概率不需要。第二个维度是数据流相关。如果我要修改一个数据结构那么所有使用这个结构的序列化、反序列化、校验逻辑都是相关的。这个维度比调用链更隐蔽但往往更重要因为数据结构的变化影响面更广。第三个维度是变更历史相关。如果某个文件最近频繁修改或者跟当前任务在同一个feature分支上有改动那它相关的概率更高。这个维度可以用git log来辅助判断。第四个维度是语义相关。有些代码在调用链和数据流上都不相关但在业务语义上相关。比如我要实现一个退款功能那么支付相关的代码虽然不直接调用但业务逻辑上是紧密关联的。这个维度需要靠人的判断或者用向量检索来辅助。5.3 实操我是怎么把上下文从8万降到1500的具体操作上我有一套固定的流程。第一步明确任务边界。在跟模型对话之前我先用一句话写清楚我要做什么。比如给用户订单接口增加按时间范围筛选的功能。这句话本身就是最好的上下文筛选器跟这个任务无关的代码一律不考虑。第二步用工具提取相关文件。我写了一个脚本输入是一个函数名或者文件名输出是调用链上下游的文件列表。这个脚本基于静态分析准确率大概在80%左右剩下的20%靠人工补充。第三步压缩文件内容。相关文件找到之后不是整个文件塞进去而是只提取相关的函数、类、接口定义。比如一个500行的文件可能只有30行跟当前任务相关那就只取这30行。压缩的时候保留函数签名和关键注释去掉实现细节。第四步维护一个上下文缓存。同一个任务往往会进行多轮对话每轮都重新提取上下文太浪费。我的做法是把提取好的上下文存到一个临时文件里每轮对话时按需加载。如果任务变了再重新提取。提示上下文压缩的时候一定要保留类型定义和接口签名。我吃过亏只保留了函数体结果模型生成的代码调用了一个不存在的参数因为签名被我省掉了。5.4 上下文工程的常见误区第一个误区是上下文越多越好。很多人觉得给模型的信息越多它越能理解我的意图。实际上恰恰相反无关信息会干扰模型的判断。我做过对比实验同一个任务给模型3个相关文件比给10个文件其中7个不相关的输出质量高出一大截。第二个误区是忽略上下文的顺序。模型对上下文的开头和结尾更敏感中间部分容易被忽略。所以重要的信息要放在开头或者结尾比如任务描述放在最前面关键约束放在最后面。第三个误区是不做上下文清理。多轮对话之后上下文里积累了大量历史信息其中很多已经过时了。比如前面讨论了一个方案后面又否决了但否决的信息还在上下文里模型可能会混淆。我的做法是每当方案确定或者方向调整时主动清理掉过时的上下文重新开始一轮对话。第四个误区是把上下文工程当成一次性工作。上下文需求是随着任务推进而变化的。开始的时候可能需要全局视野深入之后只需要局部细节。所以上下文管理是一个持续的过程不是配置一次就完事了。6. 规格驱动开发从写代码到写规格6.1 规格驱动开发解决什么问题规格驱动开发这个概念我最早是在硬件设计领域看到的。芯片设计先写规格文档然后根据规格生成验证用例最后再实现电路。软件领域借鉴这个思路核心是先把要做什么用结构化、可验证的方式描述清楚然后再让代码去实现这个描述。它解决的核心问题是需求在传递过程中失真。产品经理说用户要能快速找到商品开发理解成加一个搜索框测试理解成搜索框能输入文字最后上线发现用户想要的是按图片搜索。规格驱动开发要求把快速找到商品翻译成明确的、可验证的规格比如用户输入关键词后系统在500毫秒内返回匹配的商品列表匹配规则包括名称模糊匹配和分类精确匹配。这个规格一旦确定代码实现、测试用例、验收标准都围绕它展开减少理解偏差。6.2 规格怎么写结构化的三个要素我实践下来一份好的规格至少包含三个要素。第一个要素是输入输出定义。输入是什么类型、什么范围、什么格式输出是什么结构、什么精度、什么错误码。这部分要精确到可以直接生成接口定义的程度。第二个要素是行为描述。在什么条件下触发什么动作条件之间的优先级是什么异常情况怎么处理。这部分最好用决策表或者状态机来描述比自然语言更不容易产生歧义。第三个要素是验收标准。怎么判断这个规格被正确实现了通常是一组测试用例包括正常路径、边界条件、异常路径。这些用例可以直接作为自动化测试的输入。我现在的习惯是在写任何实现代码之前先用YAML或者类似的结构化格式把规格写出来。写规格的过程本身就能发现很多需求上的模糊点。经常出现的情况是写到一半发现某个条件没定义清楚这时候去找产品经理确认比写完代码再返工成本低得多。6.3 从规格到代码自动化能走多远规格写完之后能自动生成代码吗我的经验是部分可以但不能全自动。可以自动生成的部分包括接口定义、数据模型、参数校验逻辑、基础的CRUD操作、单元测试骨架。这些部分结构固定从规格到代码的映射关系明确用模板引擎就能搞定。不能自动生成的部分包括复杂的业务逻辑、性能优化、异常恢复策略、与其他系统的集成。这些部分需要人的判断和经验规格只能描述做什么没法描述怎么做。我的做法是用规格生成代码骨架然后人工填充核心逻辑。这样既保证了接口和数据结构的一致性又保留了人工判断的空间。生成的部分大概占60%人工写的占40%总体效率比纯手写提升一倍以上。6.4 规格驱动开发的团队落地经验在团队里推行规格驱动开发最大的阻力不是技术而是习惯。开发同学习惯了拿到需求就写代码觉得写规格是额外负担。我的经验是不要一上来就要求全团队执行先在一个小项目上试点用数据说话。我们试点项目的对比数据是写规格花了2天实现花了3天测试花了1天总共6天。对照项目没写规格实现花了4天测试花了3天因为反复发现理解偏差总共7天。而且试点项目的线上bug数量是对照组的三分之一。数据摆出来之后团队的接受度明显提高。另一个经验是规格的粒度要适中。太粗了起不到约束作用太细了写规格的时间比写代码还长。我的建议是规格描述到接口级别就够了不需要描述到函数内部实现。比如描述查询订单接口接受时间范围参数返回订单列表不需要描述用二分查找定位时间范围。注意规格是需要维护的。代码改了规格没改规格就失去了权威性慢慢就没人看了。我的做法是把规格文件跟代码放在同一个仓库代码评审的时候同时检查规格是否更新。CI里也加一个检查如果代码的接口签名变了但规格没变就报错。7. 这五个东西怎么配合使用单独看这五个点每个都有价值。但真正有意思的是把它们串起来用。我的工作流是这样的接到一个需求先用规格驱动开发的方式把需求翻译成结构化规格。写规格的过程中用上下文省98%的思路只提取跟这个需求相关的代码和文档作为参考。规格确定后用懒开发的原则评估哪些部分能用现成的库哪些部分能自动生成哪些部分必须手写。然后按照ADHD输出技能的方法把实现任务拆成原子级别逐个完成。最后用架构图校验渲染来验证实现是否符合预期的架构约束。这套流程跑下来我的体感是前期花在规格和上下文准备上的时间多了但后期返工和调试的时间大幅减少。总体效率提升大概在40%左右而且心理负担轻了很多因为每一步都有明确的完成标准和恢复点。当然这套方法不是银弹。它更适合中等规模以上的项目对于一次性脚本或者原型验证反而显得笨重。另外它对团队协作的要求比较高如果只有你一个人用这套方法而其他人还是老样子效果会打折扣。8. 几个我踩过的坑和对应的解法第一个坑是工具链太复杂。我一开始想把每个环节都用最好的工具结果光是配置工具就花了一周真正干活的时间反而少了。后来我精简到只保留三个核心工具一个看板、一个代码生成脚本、一个上下文提取脚本。其他环节能用命令行就用命令行能用现成工具就用现成工具。第二个坑是规格写得太完美。我有一次花了两天写规格把每个边界条件都考虑到了结果实现的时候发现需求变了规格全部作废。后来我调整策略规格写到80%的把握就动手剩下的20%在实现过程中补充。规格是活的文档不是一次性的合同。第三个坑是上下文压缩过度。有一次为了省token我把上下文压得太狠结果模型生成的代码引用了一个不存在的工具类。后来我定了一个底线类型定义、接口签名、关键配置这三类信息无论多长都不压缩。第四个坑是架构图校验规则太严。我一开始设了二十多条规则每次提交都报一堆警告团队很快就烦了。后来我把规则分成阻断和提醒两级只有严重的不一致才阻断合并其他的只提醒不拦截。这样既保证了关键约束又不会造成太多噪音。第五个坑是原子提交太碎。前面提过我一开始把任务拆得太细一天提交几十次git历史乱得没法看。后来我定了一个规则每个原子提交必须对应一个可验证的完成状态如果两个提交之间没有可验证的差异就合并成一个。9. 最后分享几个实用的小技巧关于上下文管理我还有一个技巧给常用的代码片段打标签。比如用户认证、数据库连接、错误处理这些高频出现的逻辑我提前整理成标准片段需要的时候直接引用标签而不是每次都去搜索文件。这样既节省了提取时间又保证了上下文的一致性。关于规格驱动开发我建议从接口规格开始不要一上来就搞全系统规格。选一个最近要做的接口用结构化的方式把输入输出、行为、验收标准写清楚然后走一遍完整流程。跑通一个之后再推广到其他接口。关于架构图校验我的经验是先从服务依赖图开始。因为服务之间的依赖关系最容易出错也最容易导致线上故障。把服务依赖校验跑通了再逐步扩展到数据流和部署架构。关于懒开发我有一个判断标准如果一段代码我写了三遍以上那它就应该被抽象或者生成。如果只写了一遍哪怕看起来有点重复也先放着等出现第三次的时候再处理。关于ADHD输出技能最重要的一点是接受自己会被打断。不要试图创造一个完全不被打扰的环境那不现实。而是假设随时会被打断然后围绕这个假设来设计工作流。这样心态上会轻松很多效率反而更高。这套方法我用了大概半年最大的感受是开发这件事写代码本身占的时间其实不多更多的时间花在理解需求、设计方案、调试问题上。把后面这些环节的效率提上来比单纯追求敲代码的速度有意义得多。
