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输出技能，最重要的一点是：接受自己会被打断。不要试图创造一个完全不被打扰的环境，那不现实。而是假设随时会被打断，然后围绕这个假设来设计工作流。这样心态上会轻松很多，效率反而更高。
这套方法我用了大概半年，最大的感受是：开发这件事，写代码本身占的时间其实不多，更多的时间花在理解需求、设计方案、调试问题上。把后面这些环节的效率提上来，比单纯追求敲代码的速度有意义得多。
