别再用旧方式玩AI编程：8个已过时的agentic开发习惯

一位YouTube博主最近连续和大约50位独立开发者、创业者一对一交流，观察他们如何用AI构建项目。结论相当尖锐：如果你现在还在用今年三四月份的方式做agentic编程，你正在严重浪费生产力，而且会被时代甩在后面。

这个观点的核心前提是：AI模型已经迭代到新一代（视频中提到Astra、Opus 5.5等），而很多人的工作流还停留在旧模型时代——那时的AI确实不靠谱，于是人们发明了大量补丁式的技巧来对抗它。问题是，这些技巧现在反而成了累赘。

需要说明的是，这套方法论有明确的适用边界：它面向独立开发者和早期创业者，而非为Google、微软或医疗软件工作的工程师。博主反复强调，给公司做医疗软件的agentic编程，和为验证一个副业点子而写代码，是两种完全不同的工作流。

旧模型时代的补丁，现在都是负担

博主指出的第一个普遍问题，是人们仍然像对待2025年那代模型一样对待AI。当年的agent会假装理解你的意图，说"好的我明白了"，然后跑偏去做一堆你没要求的事。为了对抗这种行为，大家在 agents.md 或 cloud.md 文件里塞满了"绝对不要做X""任何情况下都不许Y"这类否定性指令。

他的建议很直接：删掉这些文件，从零开始。用最新一代模型，只有当你亲眼看到模型出现你不喜欢的行为时，才往文件里追加规则。而他自己的实践是——agents.md 里几乎没有任何否定性指令，只有像"每次请求后提交你的改动"这样的正向约定。

第二个常见错误是构建复杂的"工厂系统"：一个orchestrator agent指挥十几个子标签页，通过message bus互相通信，搭配一整套脚本。这些在2025年是聪明人为了让糟糕的AI能干活而想出的拟物化架构。博主的态度同样干脆：全部删掉，这些花哨的hack正在拖慢你。

Agentic编程是指让AI模型作为自主"代理人"（agent）连续执行多步骤任务的编程范式，区别于传统的单轮问答式代码补全。在这种模式下，agent会自行读取代码库、调用工具、做出决策并提交修改，整个过程无需开发者逐步介入。Orchestrator架构是早期agentic编程中的常见设计模式：由一个中央agent（orchestrator）拆解任务并分派给多个子agent，子agent之间通过消息总线（message bus）通信协作，类似流水线工厂。这种架构在模型能力有限时能约束AI行为、减少错误扩散，但代价是系统复杂度极高、调试困难，且大量工程精力消耗在"管理AI"而非"构建产品"上。随着模型自身推理和指令遵循能力的大幅提升，此类脚手架式架构的必要性已大幅降低。

停止把上下文当圣物

最普遍的问题，是人们把上下文（context）看得过于神圣。

典型表现之一：让agent在每次改动后写笔记，把markdown文件提交到仓库，好让后续agent理解之前发生了什么。博主认为这完全没必要——代码本身就是笔记，代码就是spec。对agent来说，英文、代码、像素都是token，没有区别。你人为制造两个真相来源（source of truth），只会同时拖慢你和agent。

另一个方向的表现是spec驱动开发：把一两句话交给agent，让它先生成一份详细文档，再交给下一个agent执行。博主认为这是多此一举——能把一两句话变成完整文档的agent，就是能把这一两句话直接变成代码的同一个agent。2025年你确实需要长而详细的spec，否则agent会瞎发挥且成本高昂，但现在模型已经能给出合理的默认选择。

第三个相关误区是把对话当圣物。很多人维护着几个动辄上百条回复的"超级线程"，因为觉得里面积累了太多上下文舍不得重开。博主的做法恰恰相反：每个功能开一个新对话。点"+"，写几句话，发送，完成后直接关掉，当它从没存在过。神圣的是代码库，不是你和agent的英文对话。

在大语言模型的工作机制中，**上下文窗口（context window）**是模型在单次推理时能够"看到"的全部信息量，包括对话历史、代码文件、指令文档等。早期模型上下文窗口较小（通常8K至32K token），超出限制后模型会"遗忘"早期内容，因此开发者需要精心设计外部笔记和摘要机制来弥补。当前新一代模型的上下文窗口已扩展至数十万乃至百万token量级，能够直接读取整个代码库，"代码即文档"的主张正是建立在这一能力跃升之上。Spec驱动开发（spec-driven development）是指先由AI生成详细规格文档，再由另一个AI根据文档执行实现，这一流程在旧模型下能减少歧义、降低幻觉率，但在新模型具备更强默认推理能力后，这一中间层往往只是徒增延迟。

To-do列表和代码质量的执念

第六个观察针对的是那些还没验证想法就排满未来一个月Kanban看板的独立开发者。博主认为，对于一个还没验证市场需求的副业项目，to-do列表本身就是一种反模式（anti-pattern）。

他的替代方案是：当你冒出"应该加个功能"的念头时，别记到清单里——直接打开agent，输入这个想法，发送，让它当场做掉。这比记录、再回来、再排优先级更快。而如果一个想法"现在不值得做，那以后也不值得做"。如果担心忘掉？那就忘掉好了，真正重要的东西自然会浮上来。他警告很多人是沉迷于"生产力色情"（productivity porn），躲进小黑屋闷头造30、60天，却迟迟不把产品交到早期用户手里获取真实反馈。

第七个执念是代码质量。博主提到有非技术背景的人因为担心代码质量而暂停项目，他反问：连想法都还没验证，为什么要操心代码质量？他类比2016年前后的做法——想验证一个点子时，你会让某个20岁的年轻人一夜之间糊出一个概念验证，代码一塌糊涂，这本就是"快速试错"模式的常态。他甚至打赌，Astra产出的代码质量可能比2016年pre-MVP创业公司的代码还要好。

他并非说代码质量不重要，而是强调：在验证市场需求的阶段，代码库在你拿到前100个客户之前会以上千种方式改变，过早投入是浪费。

用workshop取代来回拉扯

博主展示了新工作流的一个亮点：让Astra先"workshop"（方案演示）几个设计方向。它一次给出了四个UX方案，你只需说"build O2"（选第二个），它就会以接近100%的还原度实现你看到的效果。

这样做的价值在于避免拉扯。旧方式是先让agent直接构建，然后不断说"我不喜欢这个、不喜欢那个、让它更醒目一点"，陷入无休止的bickering（争执）。而在workshop阶段修改是廉价的，因为agent知道这些文件是一次性的、可丢弃的。

博主给出一个重要判断标准：**如果你在和agent反复争执，那一定是哪里出了问题。**很可能是你给了太多指令、太多护栏、太多系统约束，把agent限制在单一车道里，而不是只告诉它任务和验收标准，让它自己找解法。也可能是你的 agents.md 太严格，或者你要求agent在开始前读完所有文档。他坦言自己曾在做名为Shape的产品时，创建过一本"一切的圣经"，要求agent每次改动前先通读——结果同样是场噩梦。

扔掉分支和worktree

第八点可能最具争议：停止使用git worktree和feature分支。

博主坦言这会让很多人"想把他绑上火刑柱"。他的逻辑是：2025年到2026年初你确实需要worktree和分支，因为那时agent会互相覆盖、删除彼此的改动，一片混乱。但用Astra High之后，他可以在main分支上同时跑六个任务而没出过事故。在Ship Academy和Enjoy这两个项目的整个生命周期里，他没用过一个worktree或feature分支，全在main上。

他确实会做一点"心理过滤"：六个任务并行时，保证它们在范围上大致隔离，绝不会让三个任务都去改同一个网站hero区块。他的核心机制是一条简单指令——每次改动后提交。这样六个agent各自提交自己那块工作，如果某个搞砸了就让它revert，全部完成时不会留下一堆未暂存文件。agent们甚至会主动标记"我的工作被另一个agent覆盖了"。

Git worktree是Git提供的功能，允许同一个仓库在文件系统中同时检出多个工作目录，每个目录对应不同分支，互不干扰。在多个AI agent并行修改代码的场景下，worktree可以物理隔离各agent的工作空间，避免文件冲突。Feature分支（功能分支）则是Git Flow等工作流中的标准实践，为每个新功能创建独立分支，开发完成后合并回主干，保证主分支始终处于可发布状态。博主建议抛弃这两者的前提，是新一代模型具有更强的冲突感知和自我协调能力，加之"每次改动立即提交"的约定提供了细粒度的回滚点，使main分支上的并行作业在任务范围隔离良好时风险可控。这一建议在团队协作或需要严格代码审查的场景下并不适用。

模型选择与总体心法

关于工具，博主的建议是别再用"funky"模型（如Gemini）——如果你在做一个想赚钱的项目，最低不要低于Opus，Opus是很好的日常驱动。在Codex上不要低于Astra。对于涉及架构或需要改动大量文件的新功能，默认把effort等级调到high。他也提到Sol、Terra、Six等新模型刚出来，但目前Astra仍难以超越。

他还给出一个提速的心智模型：如果你一次只做一件事、干等它跑完，会觉得什么都慢；但如果你能同时管理四个对话、四件事，就总有事情在推进，整体节奏会飞快。

贯穿全文的心法只有一句：从最幼稚、最简单的做法开始——一个分支，尽可能简短的描述，然后只在当前模型真的失败时才去调整工作流。把你2025年的老工作流全扔掉，假装自己是第一次接触agentic编程，没有任何先入为主的观念，遇到问题再修正。