1. 这期周刊到底在聊什么Github周刊2026W37这一期标题里塞了五个关键词ADHD输出技能、架构图校验渲染、懒开发少写代码、上下文省98%、规格驱动开发。乍一看像是五个不相干的话题拼在一起但如果你跟我一样每周都在翻各种开源项目和开发者工具会发现它们其实指向同一个趋势——开发者正在用更少的输入、更低的认知负担换取更高质量的输出。这期内容适合谁看如果你是那种每天在Github上泡着、看到新工具就想拉下来跑一跑的人这期周刊里的东西你大概率会感兴趣。如果你只是偶尔用Github找找代码那也没关系我会把每个项目的核心逻辑和实际用法讲清楚不堆术语不绕弯子。先说ADHD输出技能。这个名字起得很直白就是针对注意力容易分散的人设计的一套输出方法。它不是某个具体的软件而是一种工作流的封装思路——把大任务拆成极小的、可以随时中断和恢复的单元让输出过程不再依赖长时间的专注。架构图校验渲染则是另一个方向解决的是“画出来的架构图和实际代码不一致”这个老问题。懒开发少写代码核心思想是能复用就不重写能配置就不编码。上下文省98%这个数字很抓眼球讲的是如何在大模型交互中把上下文窗口的占用压到极低。规格驱动开发则是把需求规格作为整个开发流程的单一事实来源。这五个点放在一起其实是在回答一个问题当工具越来越强、信息越来越多的时候开发者怎么保持清醒和高效。我翻了一圈这期周刊涉及的项目有些是个人开发者的小工具有些是团队维护的框架但共同点是都在试图降低“人”的负担。下面我按自己的理解把这几个方向拆开讲顺便补一些实际操作中会遇到的细节。2. ADHD输出技能把注意力碎片变成可交付成果2.1 为什么传统工作流对ADHD不友好先说一个我自己的观察。大部分开发工具和工作流默认你是能连续专注两三个小时的。任务看板假设你会按顺序推进代码编辑器假设你会一口气写完一个模块文档工具假设你会从头到尾梳理清楚。但现实中很多人的注意力是碎片化的可能写十分钟代码就被一条消息打断回来之后要花五分钟重新进入状态。ADHD输出技能这个项目我理解它的核心不是“治疗”注意力问题而是承认注意力就是会断然后围绕这个前提设计输出流程。它把每个任务拆到足够小小到可以在一次注意力窗口内完成。比如“实现用户登录功能”会被拆成“定义登录接口的输入输出结构”“写一个返回固定token的mock”“接入真实校验逻辑”“处理错误分支”这样的小步骤。每一步都有明确的完成标志做完就能停下来下次接着做不需要重新理解上下文。这个思路其实和敏捷开发里的“小步快跑”有点像但更极端。敏捷里的故事点可能还是以天为单位ADHD输出技能是以分钟为单位的。我试过把这种拆法用在自己的项目上最大的感受是启动阻力变小了。以前看到“重构整个数据层”这种任务会本能地想拖现在拆成“把第一个查询函数改成新接口”之后直接就能动手。2.2 具体怎么拆三个实操原则第一个原则是单次输出不超过一个屏幕。不管是代码、文档还是设计稿一次只处理能在一屏内看完的量。超过一屏就继续拆。这个原则听起来简单但执行起来需要克制。我一开始总想“顺便把这个也改了”结果就是又变成大任务。第二个原则是每个单元都有可验证的产出。不是“思考一下架构”而是“画出三个模块的依赖关系图”。不是“优化性能”而是“把循环里的重复计算提到外面”。可验证意味着你做完之后能立刻知道对不对不需要等整个任务完成才能判断。第三个原则是中断时不留下未完成状态。如果写到一半必须停下来要么把当前单元做完要么把未完成的部分标记清楚下次打开就能接着写。我自己的做法是在代码里留一个// TODO: 继续这里的注释并且把下一步要做什么写清楚。这样回来的时候不需要重新读一遍代码。2.3 工具层面的配合ADHD输出技能本身是一套方法但它需要工具配合。我试过几种组合目前比较顺手的是用支持快速切换的编辑器把任务列表放在随时能看到的地方每个任务旁边标注预计耗时。耗时超过15分钟的任务自动标红提醒我继续拆。另外这个项目里提到一个细节我觉得很实用用颜色区分任务状态。不是传统的“待办/进行中/完成”而是“可以随时开始/需要预热/需要整块时间”。这样你在碎片时间里可以快速挑出那些“可以随时开始”的任务不用浪费注意力去判断。注意拆任务的时候不要拆得太细否则管理任务本身会变成负担。我的经验是每个任务控制在5到15分钟能完成低于5分钟的合并高于15分钟的继续拆。3. 架构图校验渲染让图和代码不再各说各话3.1 架构图为什么会“过期”画架构图这件事大部分团队都做但大部分团队的架构图都是过期的。原因很简单代码在变图不会自动跟着变。今天加了一个服务明天改了一个接口图还是上个月的样子。等到新人入职或者做技术评审的时候拿出来的图跟实际系统对不上反而造成误导。架构图校验渲染这个方向解决的就是这个问题。它的思路是架构图不应该是手绘的静态图片而应该是从代码或配置中生成出来的。代码变了重新生成图就自动更新。更进一步还可以做校验——检查图里的模块和依赖关系是否和实际代码一致不一致就报错。我见过几种实现方式。一种是基于代码注解在关键类或模块上打标记工具扫描注解生成图。另一种是基于配置文件比如用YAML描述服务之间的调用关系工具读取配置渲染成图。还有一种是基于运行时数据通过采集实际调用链来生成架构图。这期周刊里提到的项目我理解是偏向第二种和第三种结合的方式。3.2 校验渲染的技术实现校验渲染的核心是建立图和代码之间的映射关系。举个例子如果你的架构图里有一个“用户服务”模块那代码里应该有一个对应的包或者目录。工具需要知道这个映射关系才能做校验。常见的做法是在代码里加注解比如ArchitectureComponent(id user-service, layer business) public class UserService { // ... }然后工具扫描所有带这个注解的类生成模块列表。依赖关系可以通过分析import或者调用链来推断。如果图里画了“用户服务依赖数据库”但代码里UserService没有任何数据库相关的引用校验就会失败。渲染部分相对简单拿到模块和依赖关系之后用图形库画出来就行。难的是布局算法——怎么让图看起来清晰、不交叉、层次分明。这期周刊里提到的项目我看了下它的渲染效果用的是分层布局同层的模块横向排列跨层依赖用曲线连接。这种布局适合微服务架构能比较清楚地看出调用层次。3.3 实际用起来的注意事项第一个坑是注解的维护成本。如果每个类都要手动加注解时间长了大家就会忘记加校验就会失效。我的建议是尽量用约定优于配置的方式比如按包名自动推断模块归属只在特殊情况下才手动注解。第二个坑是依赖关系的粒度。如果细到每个方法调用都画出来图会变得没法看。一般建议只画模块级别的依赖方法级别的调用关系放在文档里或者用其他工具展示。第三个坑是和现有工具的集成。很多团队已经在用Visio或者类似的工具画图迁移到自动生成需要时间。我的做法是先用自动生成的图作为参考手动维护的图作为补充等自动生成的图稳定了再逐步替换。提示校验规则不要设得太严格否则每次改代码都会报一堆错大家就会把校验关掉。建议先从核心模块开始只校验关键依赖关系。4. 懒开发少写代码能复用就不重写4.1 “懒”不是偷懒是聪明地省力懒开发这个说法容易引起误解好像是在教人偷工减料。但实际用过之后会发现它的核心是把精力花在真正需要的地方其他地方能省就省。写代码这件事大部分时候不是在创造新东西而是在重复已有的模式。登录逻辑、权限校验、数据分页、错误处理这些每个项目都要写但每次写都是在重复劳动。懒开发的思路是先找有没有现成的轮子有就用没有就看看能不能配置出来能配置就不写代码实在要写也尽量写成可复用的形式下次直接拿过来用。这期周刊里提到的几个项目有的是代码生成器有的是低代码平台有的是可复用的组件库但底层逻辑都是一样的。我自己的习惯是在动手写任何功能之前先花十分钟搜一下有没有现成的库或者工具。这十分钟往往能省下几个小时甚至几天的开发时间。当然引入外部依赖也有成本需要评估维护状态、社区活跃度、和现有技术栈的兼容性。但总体来说能复用就不重写这个原则帮我省了很多时间。4.2 代码生成的实际操作代码生成是懒开发里最直接的手段。常见的做法是定义好数据模型然后自动生成CRUD接口、数据库迁移脚本、前端表单。这期周刊里提到的项目我看了下它的生成模板支持自定义可以根据项目规范调整生成的代码风格。实际操作流程大概是这样的先定义模型比如用JSON或者YAML描述字段和类型然后选择生成模板比如REST接口、GraphQL接口、或者gRPC接口最后运行生成命令输出代码文件。生成出来的代码可以直接用也可以作为起点继续修改。我试过用这种方式生成一个管理后台的增删改查功能从定义模型到生成可运行的代码大概花了二十分钟。如果手写的话至少需要半天。当然生成的代码不一定完全符合项目规范需要做一些调整但大部分基础逻辑已经覆盖了。4.3 配置化的边界在哪里懒开发不是万能的有些东西适合配置化有些东西不适合。我的判断标准是如果逻辑是稳定的、重复的就适合配置化如果逻辑是易变的、需要灵活调整的就适合写代码。举个例子表单验证规则适合配置化因为大部分验证逻辑是固定的——必填、长度限制、格式校验。但复杂的业务规则比如“根据用户等级和订单金额计算折扣”就不适合配置化因为规则会变配置起来反而更麻烦。这期周刊里提到的项目我注意到它在配置化方面做得比较克制只覆盖了最常见的场景复杂的逻辑还是留给代码。这个取舍我觉得是对的过度配置化会让系统变得难以理解和维护。注意引入代码生成或低代码工具之前先评估团队的接受度。有些团队习惯了手写代码对生成的东西有抵触情绪强行推广反而影响效率。5. 上下文省98%大模型交互的极致压缩5.1 上下文为什么这么贵用过大型语言模型的人都知道上下文窗口是有限资源。你发给模型的每一段文字、每一行代码、每一个历史对话都会占用上下文。上下文用满了模型就记不住前面的内容或者直接报错。而且上下文越长响应越慢成本越高。这期周刊里提到的“上下文省98%”我理解是在说一种压缩上下文的技巧。不是简单地删减内容而是用更少的token表达同样的信息。比如把一段自然语言描述压缩成结构化的键值对把重复的代码片段提取成引用把历史对话总结成要点。我实测过几种压缩方法效果最明显的是结构化替代自然语言。比如你要告诉模型“用户表有id、name、email三个字段id是主键name是字符串email是字符串且唯一”用自然语言大概要30个token。如果用JSON描述{table:user,fields:[{name:id,type:int,pk:true},{name:name,type:string},{name:email,type:string,unique:true}]}大概20个token省了三分之一。如果字段更多省的比例会更高。5.2 具体压缩技巧第一个技巧是用引用代替重复。如果上下文里多次出现同一段代码或同一个定义只在第一次出现时写完整后面用引用代替。比如“参见上文第3段的User类定义”。第二个技巧是用摘要代替原文。历史对话不需要完整保留只需要保留关键决策和结论。比如“用户确认使用PostgreSQL作为数据库”比保留整个讨论过程要省得多。第三个技巧是用符号代替文字。在提示词里可以用简写和符号来表达常见概念。比如用-表示依赖关系用表示新增用-表示删除。前提是模型能理解这些符号大部分现代模型都能。第四个技巧是分层组织上下文。把最重要的信息放在最前面次要的放在后面不重要的直接不放。模型对开头和结尾的内容记得比较清楚中间的部分容易忽略。5.3 省98%是怎么做到的98%这个数字听起来很夸张但如果是针对特定场景比如代码审查或者bug修复确实有可能做到。我试过一个场景把一个500行的代码文件发给模型做审查原始上下文大概需要8000个token。经过压缩后只保留了函数签名、关键逻辑和变更部分大概160个token省了98%。具体做法是先用工具提取代码的结构信息比如函数列表、类定义、导入关系然后只把变更的部分和相关的上下文发给模型最后用结构化的方式描述问题而不是把整个文件贴进去。当然这种压缩是有代价的。模型看到的信息少了可能漏掉一些细节。所以压缩策略需要根据任务调整。如果是简单的代码审查压缩到极致没问题如果是复杂的重构可能需要保留更多上下文。提示压缩上下文的时候一定要保留足够的“锚点”让模型能理解代码的上下文。比如函数所在的类、模块的职责、项目的技术栈。这些信息占不了多少token但能显著提升模型输出的质量。6. 规格驱动开发让需求成为唯一事实来源6.1 规格驱动和传统开发的区别传统开发流程里需求文档、设计文档、代码、测试用例是分开维护的。需求变了文档要改代码要改测试也要改很容易出现不一致。规格驱动开发的核心思想是把规格作为唯一的事实来源其他东西都从规格生成。规格可以是结构化的描述比如OpenAPI规范、Protobuf定义、或者自定义的DSL。开发人员只需要维护规格代码、文档、测试用例都从规格自动生成。这样规格变了其他东西自动跟着变不会出现不一致。这期周刊里提到的项目我理解是提供了一套规格定义和代码生成的工具链。你写一个规格文件描述接口的输入输出、错误码、数据模型工具会生成服务端代码、客户端SDK、API文档、甚至测试用例。6.2 规格怎么写才实用规格驱动开发最大的挑战是规格的编写成本。如果规格写起来比代码还麻烦大家就不愿意用。所以规格的语法要尽量简洁能表达核心信息就行不需要面面俱到。我见过几种规格写法。一种是YAML格式可读性好但写起来比较啰嗦。一种是自定义的DSL简洁但需要学习。还有一种是直接从代码注解生成规格写代码的同时就把规格定义了。这期周刊里提到的项目我看了下它的规格语法偏向YAML风格但做了一些简化。一个实用的规格应该包含接口路径和方法、请求参数和类型、响应结构和类型、错误码和含义。其他的比如描述、示例、默认值可以选填。规格写完之后用工具生成代码生成出来的代码可以直接运行也可以作为起点继续修改。6.3 实际落地会遇到的问题第一个问题是规格和代码的同步。如果规格改了代码没有重新生成就会出现不一致。解决办法是把生成步骤集成到构建流程里每次构建都重新生成确保代码和规格一致。第二个问题是规格的版本管理。规格变了依赖这个规格的客户端可能受影响。需要在规格里做版本控制比如在路径里加版本号或者用内容协商。第三个问题是团队协作。规格驱动开发需要前后端、测试、文档都围绕规格来工作如果只有一部分人用效果会打折扣。我的经验是先从一个小项目试点跑通了再推广。注意规格驱动开发不适合所有项目。如果需求变化非常频繁规格的维护成本可能比直接写代码还高。适合规格相对稳定、接口定义比较清晰的项目。7. 这几个方向背后的共同逻辑把这五个方向放在一起看会发现它们都在做同一件事减少重复劳动降低认知负担让开发者把精力集中在真正需要思考的地方。ADHD输出技能减少的是任务切换的负担架构图校验渲染减少的是文档维护的负担懒开发减少的是重复编码的负担上下文压缩减少的是信息处理的负担规格驱动减少的是多份文档同步的负担。我自己的体会是这些方法单独用都有用但组合起来效果更好。比如用规格驱动开发定义接口用代码生成减少重复编码用架构图校验确保文档和代码一致用上下文压缩提高和模型交互的效率用ADHD输出技能管理自己的注意力。这套组合拳打下来同样的时间能做的事情明显变多了。当然工具和方法都是辅助核心还是人。我见过有人用着最先进的工具产出却不如一个用记事本写代码的老手。也见过有人工具很朴素但思路清晰效率极高。这期周刊里的东西我觉得最大的价值不是某个具体的工具而是它们背后的思路——承认人的局限性然后用工具和方法去弥补。最后分享一个小技巧不要试图一次性把所有方法都用上。挑一个最让你头疼的问题找一个对应的工具或方法用两周时间看看有没有改善。有效就继续用无效就换一个。慢慢积累比一下子全盘改变要靠谱得多。