1. 从一份空壳日报说起为什么我决定把AI日报做成可复现的工程拿到AI 日报 2026-09-19这个标题的时候正文是空的关键词是空的摘要也是空的。换作两年前的我可能直接就去搜一圈新闻拼一篇今日AI大事件汇总交差了。但这次我盯着那几个热搜词看了很久——claude code、agent开发、vibe coding、deepseek harness、codex接入deepseek、ai coding 代码生成规范示例——这些词拼在一起其实指向的不是新闻而是一整套正在成型的AI编程工作流。所以这篇日报我不打算写成新闻串烧。我更想干一件事把2026年9月中旬这个时间点上围绕AI Coding和Agent开发最值得关注的技术动向拆成能落地、能复现、能直接抄作业的东西。你可能是刚装完Claude Code还在纠结怎么配VSCode的新手也可能是已经在跑多Agent工作流、想看看别人怎么组织Harness层的老手这篇内容都尽量照顾到。先给个结论性的判断这一轮AI编程工具的竞争焦点已经从模型谁更聪明转移到了工作流谁更顺。模型能力趋同之后真正拉开差距的是CLI工具链、Agent编排框架、以及代码生成规范这三件事。下面我按这个逻辑往下拆。2. Claude Code这条线从安装到VSCode集成的完整链路2.1 为什么CLI形态的编程助手突然成了主流热搜里claude code安装、claude code使用、claude cli、ubuntu安装claude code、vscode配置claude code这几个词扎堆出现说明大量人卡在装不上、配不好这一步。这背后其实有个产品逻辑的转变值得说清楚。早期的AI编程助手基本都寄生在IDE插件里你打开编辑器侧边栏弹个对话框复制粘贴代码。这种形态的问题是它和你的项目上下文是割裂的。插件能看到你当前打开的文件但看不到你的git历史、看不到你的构建脚本、看不到你整个目录结构里那些没打开的文件。而CLI形态的Agent是直接跑在你的项目根目录下的它天然拥有完整的文件系统访问权能自己grep、自己读文件、自己跑测试。这就是为什么Claude Code这类工具选择做CLI而不是做插件。它的工作模式更像是一个坐在你旁边的工程师而不是一个问答机器人。理解这一点你就能理解为什么它的配置方式和传统插件完全不同——它需要的是项目级的权限和上下文而不是编辑器级的。2.2 安装环节最容易踩的三个坑我前后在三台机器上装过Windows、Ubuntu、macOS各一次踩的坑基本能总结成三类。第一类是Node版本问题。这类CLI工具通常依赖较新的Node运行时如果你系统里是老的Node 16甚至更早装完跑起来会报各种莫名其妙的模块错误。我的建议是直接用nvm或者fnm管理Node版本切到当前LTS再装。别嫌麻烦这一步省下来的时间后面会加倍还给你。第二类是权限与路径问题。在Ubuntu上装的时候如果直接用sudo npm install -g装完之后普通用户跑命令会找不到可执行文件因为全局路径装到了root的环境里。正确做法是配置npm的全局目录到用户目录下或者用nvm装Nodenvm装的Node全局包天然在用户目录。这个坑很隐蔽报错信息也不会直接告诉你原因。第三类是Windows上的虚拟化平台提示。热搜里那条claudes workspace requires the virtual machine platform on windows. enable就是典型。这类工具在Windows上跑沙箱环境时需要系统开启虚拟化平台支持。解决办法是在启用或关闭Windows功能里勾选虚拟机平台然后重启。注意这跟某些第三方虚拟化软件可能有冲突如果你机器上装了别的虚拟化工具可能需要先处理兼容性。提示安装类问题九成出在环境隔离上。养成每个工具用独立Node版本管理的习惯能规避掉大部分玄学报错。2.3 VSCode集成不是装插件而是配终端很多人搜vscode配置claude code脑子里想的是去扩展市场搜个插件装上。但实际做法往往相反——你不需要装插件你需要的是把CLI工具集成进VSCode的终端工作流。具体怎么做我的做法是在项目根目录建一个.vscode/tasks.json把常用的Agent命令注册成任务然后用快捷键触发。这样你在编辑器里改代码切到终端就能让Agent基于最新代码干活改完再切回来review。整个循环不用离开编辑器但底层跑的是完整的CLI能力。如果你想要更顺滑的体验可以在VSCode的设置里把集成终端配置成自动激活项目的虚拟环境这样Agent跑测试、跑lint的时候用的就是你项目自己的依赖不会出现我本地能跑Agent跑就报错的尴尬。这里有个经验别让Agent用全局环境跑你的项目。我见过太多人因为Agent用了系统Python而不是venv里的Python导致依赖版本对不上排查半天以为是Agent的bug。配置好终端自动激活环境这个问题从根上就没了。3. Agent开发这条线Harness、框架与工作流编排3.1 DeepSeek Harness这个词透露了什么信号热搜里deepseek harness和deepseek hermes同时出现这两个词值得单独拎出来讲。Harness在工程语境里指的是测试/运行框架套在AI Agent上它指的是包裹在模型外面、负责调度工具调用、管理上下文、处理错误重试的那一层基础设施。为什么这个概念突然火了因为大家发现同一个模型套不同的Harness实际干活的能力差距巨大。模型本身只是大脑Harness是手脚和神经系统。一个设计良好的Harness能做到工具调用失败自动重试、上下文超长自动摘要压缩、多步任务自动拆解、执行出错自动回滚。这些能力跟模型智商无关纯粹是工程问题。所以当deepseek harness成为热搜词我理解为大家开始意识到光有好模型不够得有好马鞍。这也解释了为什么agent框架、agent项目、agent智能体这些词一直有热度——大家在找的其实不是模型是那套能把模型能力稳定释放出来的编排层。3.2 一个最小可用的Agent工作流长什么样pi coding agent 工作流使用和pi agent这两个词让我想聊聊工作流编排的实操。抛开具体产品一个能干活的最小Agent工作流我总结下来就四个环节感知读取任务描述、读取相关文件、读取项目状态git status、测试结果规划把大任务拆成可执行的小步骤每步明确输入输出执行调用工具读写文件、跑命令、调API拿到结果校验检查执行结果是否符合预期不符合就回到规划环节听起来简单但真正难的是校验环节。大部分Agent翻车都翻在这里——它执行完一个步骤自己觉得对了就往下走结果错误累积到后面才爆发。好的工作流会在每个关键步骤后插入一个独立的校验动作比如改完代码必须跑一遍测试、写完配置必须解析一遍验证语法。我自己的做法是给Agent配一个验收清单每个任务类型对应一组必须通过的检查项。比如改代码类任务验收清单就是语法检查通过、单元测试通过、lint无新增警告。Agent每完成一步自动跑清单全绿才继续。这个机制加上去之后返工率肉眼可见地下降。3.3 多Agent协作别急着上先把单Agent跑稳agent开发、agent项目这些词背后很多人一上来就想搞多Agent协作——一个负责写代码一个负责review一个负责测试。想法很好但我实测下来的建议是单Agent工作流没跑稳之前别碰多Agent。原因很实际。多Agent之间的通信成本很高而且错误会在Agent之间传播放大。A Agent写了个有问题的代码B Agent review的时候没看出来C Agent测试的时候因为环境问题也没测出来最后你拿到一个三个Agent都通过了但就是跑不起来的结果排查起来比单Agent难十倍。正确的路径是先用单Agent把感知-规划-执行-校验这个闭环跑通跑顺跑出稳定的成功率。然后你会发现很多原本想用多Agent解决的问题单Agent加更好的工具就能解决。真正需要多Agent的场景通常是任务本身可以高度并行、且子任务之间耦合很低的比如同时给十个模块写单元测试这种。4. AI Coding的争议代码质量到底会不会下降4.1 vibe coding这个词为什么让人又爱又恨vibe coding和codex vibe coding是这轮热搜里最有争议的词。它描述的是一种状态你大概描述一下想要什么AI哗哗生成一堆代码你看着差不多能跑就接着往下走全程凭感觉而不是凭理解。这种模式在原型阶段效率极高我承认。一个下午能搭出一个能演示的东西放在以前得一周。但问题在于很多人把原型阶段的习惯带到了生产阶段。原型代码可以凭感觉生产代码不行。生产代码要维护、要扩展、要给别人看、要在出问题的时候能定位。我见过最典型的翻车场景用vibe coding快速搭了个功能上线三个月后出了个bug回头一看代码没人能说清楚那段逻辑为什么那么写包括当初生成它的AI——因为上下文早丢了。这时候你面对的就是一坨能跑但没人敢动的代码。4.2 代码生成规范把感觉变成约束热搜里ai coding 代码生成规范示例这个词恰恰是对vibe coding的一种纠偏。它的思路是既然AI生成代码不可避免那就用规范去约束生成结果让生成出来的代码天然符合团队标准。具体怎么落地我的做法是维护一份项目级的AI_CODING_GUIDE.md放在仓库根目录内容包括规范类别具体要求为什么这么定命名变量用驼峰常量全大写下划线和现有代码库保持一致减少review摩擦错误处理禁止裸try-catch必须记录上下文出问题时能定位而不是吞掉异常注释只注释为什么不注释是什么代码本身说明是什么注释说明决策原因依赖新增依赖必须说明理由防止AI随手引入一堆没必要的包测试每个公开函数必须有对应测试保证后续改动有安全网这份规范的关键在于它会被Agent读取。你在让Agent干活之前先让它读一遍这份规范它生成代码的时候就会遵守。这比事后review再打回去改高效得多。4.3 一个反直觉的结论AI Coding让代码质量的两极分化更严重了我观察下来AI Coding对代码质量的影响不是整体提升或整体下降而是两极分化。有规范、有review、有测试的团队用了AI之后质量稳中有升因为重复劳动被自动化了人可以把精力放在架构和边界情况上。没规范、没review、没测试的团队用了AI之后质量断崖式下跌因为生成速度太快问题积累速度也快最后积重难返。所以AI Coding会不会让代码质量下降这个问题本身问错了。真正该问的是你的团队有没有能力接住AI带来的产出速度。接得住AI是加速器接不住AI是放大器把原有的问题放大十倍。5. 工具链选型Codex、DeepSeek与多模型接入的现实考量5.1 为什么大家开始讨论codex接入deepseekcodex接入deepseek这个词反映了一个很实际的需求不想被单一模型绑定。Codex这类工具的价值在于它的工作流和工具链而模型是可以替换的。把DeepSeek接进去本质上是想用更可控的成本拿到够用的能力。这种工具链和模型解耦的思路我认为是接下来一年的主流。原因很简单模型迭代太快了今天最强的模型三个月后可能就被超越。如果你的工作流深度绑定了某个模型每次模型换代你都要重做一遍集成。但如果你的工作流是模型无关的换模型就像换个发动机底盘不用动。实操上怎么做核心是把模型调用抽象成一层接口。你的Agent不直接调某个厂商的API而是调你自己封装的一层这层负责路由、重试、降级。这样你想换模型改一个配置就行。我自己的项目里就是这么做的从最初接一个模型到现在能同时接三四个切换成本几乎为零。5.2 成本与能力的平衡点在哪coding plan、mimo coding plan这些词说明大家在认真算账了。我的经验是不要一刀切地用最贵的模型或最便宜的模型而是按任务分级。简单任务——比如格式化代码、写注释、生成样板代码——用便宜快速的模型就够了这些任务对智商要求低对速度要求高。复杂任务——比如重构、设计架构、排查疑难bug——才上最强的模型。我粗略算过这样分级之后整体成本能降一半以上而实际产出质量几乎没差别。具体分级标准可以这样定任务能否用一句话描述清楚能就是简单任务。任务是否需要理解多个文件的关联需要就是复杂任务。任务是否需要做权衡取舍需要就是复杂任务。这个判断标准不完美但足够实用。5.3 那些无限制类工具的真实定位热搜里混进来一些无限制无审核生成式ai、无禁词虚拟ai聊天免费之类的词。这类工具我不做具体推荐但可以聊聊它们反映的需求很多人需要的是一个没有太多使用门槛、能快速试错的沙盒环境。这个需求本身是合理的。学习和实验阶段你不想被各种限制卡住。但我的建议是实验环境和生产环境要严格分开。实验阶段你可以随便试但任何要进入生产的东西都必须经过规范化的流程。把沙盒里的东西直接搬到生产是很多事故的源头。6. 把日报变成可复用的方法论我的实操清单6.1 每天花15分钟做一次工具链体检与其追每天的新闻不如建立自己的信息过滤机制。我的做法是每天早上花15分钟只关注三类信息我当前用的工具是否有更新、我关注的框架是否有破坏性变更、社区里是否出现了能解决我当前痛点的新方案。其他一律不看。这个习惯的价值在于把被动接收变成主动筛选。新闻是无限的你的注意力是有限的。与其被信息流推着走不如带着问题去找答案。你手头正在卡的那个问题才是你最该关注的信息。6.2 建立自己的踩坑日志我从去年开始维护一个PITFALLS.md记录每次踩坑的完整链路现象是什么、我一开始怎么想的、实际原因是什么、怎么解决的、下次怎么避免。这个文件现在有几十条记录价值极高。为什么强调完整链路因为只记结论没用要记推理过程。下次遇到类似问题你需要的不是答案是X而是当时我是怎么一步步排除到X的。排查思路比答案更可复用。6.3 给Agent配一份项目说明书这是我觉得投入产出比最高的一件事。在项目根目录放一份PROJECT_CONTEXT.md写清楚这个项目是干什么的、目录结构怎么组织的、核心模块之间的依赖关系、常用的命令有哪些、有哪些坑不能踩。每次让Agent干活之前先让它读这份文件。效果立竿见影——Agent不再问一些基础问题生成的代码也更贴合项目实际。这份文件你写一次后面所有Agent任务都受益。而且写的过程本身也是梳理项目的过程一举两得。6.4 定期做AI产出审计每隔一段时间我会抽查一批AI生成的代码看看它们的实际表现有没有引入隐藏bug、有没有违反规范、有没有留下技术债。这个审计不是为了否定AI而是为了校准你对AI当前能力的判断。因为AI能力在快速变化你三个月前形成的AI干不了这个的印象可能现在已经过时了。定期审计能让你及时更新认知把更多任务放心交给AI同时也能及时发现AI在哪些方面开始飘了需要加强约束。7. 关于这套工作流我踩过的最深的几个坑先说一个最反直觉的Agent跑得越顺你越要警惕。我有一次让Agent重构一个模块它一路绿灯跑完测试全过我扫了一眼觉得没问题就合并了。结果上线后发现一个边界情况没处理——那个边界情况恰好不在测试覆盖范围内。Agent之所以顺是因为它只在你给的约束范围内优化约束之外的它看不见。所以约束的完备性比Agent的能力更重要。第二个坑是上下文污染。Agent在一个长会话里干活前面聊过的无关内容会一直占着上下文影响后面的判断。我的做法是任务切换时果断开新会话把必要的背景重新喂一遍。虽然麻烦但比让Agent带着一堆无关记忆干活靠谱得多。第三个坑是过度信任工具调用结果。Agent跑了个命令返回成功它就认为成功了。但命令返回成功不等于结果正确——比如测试命令返回0可能是因为压根没跑到测试用例。所以关键步骤的结果校验一定要用独立的方式再做一遍不能只信Agent自己的判断。最后一个也是我觉得最重要的别让AI替你做决策。AI可以帮你写代码、查资料、跑测试但这个方案要不要上、这个取舍怎么定这类决策必须你自己来。因为决策背后是业务理解、是团队情况、是长期规划这些AI看不到。把决策权交出去短期省事长期失控。这套东西我用了大半年最大的体会是AI编程工具真正的价值不在于它能替你写多少代码而在于它逼着你把原本模糊的东西想清楚。你要给它写规范就得先想清楚规范是什么你要给它配上下文就得先理清项目结构你要校验它的产出就得先定义什么叫对。这个过程本身就是在提升你自己的工程能力。工具在进化用工具的人也得跟着进化这才是这轮变化里最实在的东西。
