一个人、九个月、20万行代码、每个月烧掉40亿 token——这些数字放在一起外人可能会以为是一个小团队在冲刺但确实是一个人在造一款Harness架构应用时的真实账单。不是标题党也不是段子而是我过去九个月的真实节奏白天写设计、晚上喂AI、周末重构月均tokens消耗稳定在40亿以上。今天把这九个月的思路、踩坑和数据整理出来对想用AI辅助独立开发的朋友应该有点参考价值。先回答大家最关心的问题这款Harness架构应用到底做什么简单来说它是一套面向AI工作流的执行框架把模型调用、工具执行、状态管理和安全校验封装成可插拔的层让AI能力可以稳定地接入业务场景。说白了就是给AI这匹烈马套上马具让它既能跑得快又不会脱缰。1. 先交代背景为什么一个人敢碰Harness架构1.1 一句话说清Harness架构好多朋友第一次听到“Harness架构”都问同一个问题这东西跟微服务、事件驱动有什么区别是不是又一个造出来的概念我的回答是Harness架构不是全新的架构范式而是一种专门为AI应用设计的代码组织方式。它把应用拆成五层——模型接入层、工具执行层、状态管理层、安全校验层、编排层每层有清晰边界层与层之间只通过接口通信。这样做的直接好处是AI生成代码时只要约定好每层的接口它就能按模板填代码不大会出现“生成一个函数结果它顺手改了别的模块”的情况。Harness这个词的英文原意是“马具”。烈马有跨越复杂任务的潜力但能不能安全地骑上去、控制方向取决于缰绳、马鞍设计得好不好。Harness架构就是那副马具它不提供模型能力但决定了模型能力能不能被稳定地、安全地用起来。我见过太多AI应用模型效果好得一塌糊涂一接进生产环境就崩原因不在模型而在承载模型的这套“鞍具”做得太粗糙。这个概念本身不是学术定义更像是我在实践里总结的工程经验。对个人开发者来说它的价值在于把“让AI做事”变成“让AI在我划定的安全区内做事”这对后续九个月批量产代码至关重要。1.2 为什么一个人花九个月做这个很多人听到“一个人20万行代码九个月”会觉得我疯了。为什么不先做个简单的小工具跑通一个需求再慢慢迭代其实这个选择背后有三层考虑。第一AI应用正在快速从“单一模型调用”走向“多工具编排”。真正卡住应用的往往不是模型效果而是“代码架构扛不住复杂AI交互”。市面上的重框架适合团队轻框架只适合做Demo中间恰好空出一块“个人开发者用得上、又愿意接受低成本”的地带。我想填的就是这个空档。第二单人开发最大的优势是决策链路短。架构上任何地方不顺眼我可以当天就暴力重构不需要说服同事。团队里常见的“架构演进需要评审”在这里完全不成立。九个月里我确实重构了好几次每次都是说改就改这是我敢碰重架构的底气。第三我想真实验证一件事在AI辅助编程已经足够成熟的今天一个人到底能不能在九个月内交付一个团队级别复杂度的产品。结论是可以但前提是——你得有意识地管理token、管理上下文、管理AI产出代码的质量而不是把AI当无限生成器。2. AI辅助开发20万行代码是怎么和AI“结对”写完的2.1 每个月的token账单到底花在哪先放数据。不含闲聊和实验性调用我每个月的token消耗大致分成四块用途占比月消耗量约说明代码生成55%-60%22亿-24亿新功能、单元测试、配置、脚手架重构与解释20%-25%8亿-10亿存量代码梳理、性能优化、跨模块问题定位调试与排错10%-15%4亿-6亿分析日志、堆栈、让AI解释报错原因文档与设计5%-10%2亿-4亿架构文档、README、注释、API说明按通用token计数规则1个token大约对应0.75个英文单词。40亿token粗略折算就是30亿个单词平均每天一亿多个token输入到模型API里。这大概是我这个项目最大的一笔运行成本也是很多人听到数字就会被吓住的地方。好在我消耗的不是一次性算力而是有效产出。代码生成部分真正落进仓库的比例前三个月只有三成左右到后面稳定在六到七成——这说明AI辅助开发的效率很大程度取决于你怎么提需求而不只取决于模型有多强。2.2 我拆任务的“代码原子化”方法20万行代码如果指望AI一句话生成结果大概率是一堆让人崩溃的垃圾。我摸索出一套叫“代码原子化”的拆解方法把一个完整功能不断向下拆拆到每个任务足够小小到AI能稳定输出一个高内聚的文件或者函数。一个“代码原子”的典型特征单个文件最多不超过200行只有一个核心职责名字里就说得清输入输出类型在任务描述里提前定义好不允许AI自由发挥依赖的外部接口在上下文里给全不存在的模块绝不引入拆解的起点是架构图。我先把系统拆成模块再拆服务再拆函数最后才算“可以交给AI的最小单元”。这一步看起来多花时间但实际上是在替AI降低出错的概率。实测下来直接让AI写一个20行函数成功率高到离谱让AI直接写一个完整业务模块则大概率要返工两三轮。举个例子早期我做后台的订阅计费模块让AI一口气生成“创建订单校验套餐扣费生成发票”整个链路的代码改了四遍才勉强通过。后来我把它拆成“校验套餐”“检查余额”“扣费”“生成发票”四个原子任务每个任务单独交付总耗时反而只有原来的三分之一。2.3 四段式提示词模板和上下文“断舍离”同样的模型同样的量级用不同的描述方式AI产出质量能差三倍以上。我固定下来的模板是四段式【任务】你要实现什么功能做到什么程度 【约束】不能用什么必须遵守什么项目规范 【示例】给出输入输出的具体样例 【验收】代码满足什么标准才算通过模板本身不神奇神奇的是“强制AI按模板走”这个动作。它把模糊的开发意图变成了可校验的交付标准返工率肉眼可见地下降。比如写一个接口服务任务描述里如果不写“输入参数必须是字符串非法输入返回400”AI很可能自己发明一套异常处理逻辑返回的格式跟全局协议对不上。上下文管理是我控制token成本的关键。刚开始我走过一个弯路把整个项目的说明文档、接口定义、所有相关代码全部都塞进上下文生怕AI信息不足。结果token爆炸而且模型处理长上下文时注意力会被稀释垃圾代码反而变多。后来我改成了“按模块开独立会话”每个会话只携带当前模块的接口定义、关键代码片段和少量示例每次对话快结束时让AI生成一段精简的摘要把它存到临时文件。下次继续时只需要把摘要灌回上下文。实测下来这种“上下文断舍离”让单次任务成本下降了将近40%代码质量反而更稳定。3. Harness架构落地五个关键层的设计与实现3.1 模型接入层为多模型切换留好后路Harness架构的最底层是模型接入层核心是一个叫ModelPort的抽象接口from abc import ABC, abstractmethod from typing import Any class ModelPort(ABC): abstractmethod async def chat(self, messages: list[dict], tools: list[dict] | None None) - dict: 统一对话入口 abstractmethod async def stream_chat(self, messages: list[dict], tools: list[dict] | None None): 流式对话供需要持续输出的场景使用所有模型实现都实现这个接口业务代码永远只依赖ModelPort不关心底层是哪个模型。这块最大的难点不是模型能力的高低而是协议差异有的模型有function calling能力有的没有有的支持流式返回有的不支持有的参数命名还不一样。我在接入层里统一把这些差异拦掉业务侧看到的永远是同一种消息格式后面加新模型时业务代码不需要跟着动。这个设计在最开始显得有点“过度设计”一上来就搞抽象。到了第七个月我要接入第二个模型做路由备份时发现它值回了票价只改一个配置文件新增一个实现类业务代码一行没动。如果你也在做AI相关应用别嫌接口抽象麻烦多花半天定义一个稳定的模型入口后面能省好几个通宵。3.2 工具执行层让AI“动手”之前先过三关工具执行层是Harness架构里最重的一层。它解决的核心问题是当模型说“我想调用某个函数”时系统怎么安全、可控地让这个调用真正发生。我的实现是“注册表沙箱”的组合。每个对外能力都注册成一个带schema描述的工具tool(search_documents, description搜索本地文档库) async def search_documents(query: str, top_k: int 5) - list[Document]: ...工具执行之前我一定会做三层检查参数类型校验模型给出来的参数类型对不对、值是否在合法范围内资源权限校验这个工具在当前会话里是否有权限被调用返回值容量校验返回值会不会太大撑爆后续流程没有这三层检查模型一旦产生幻觉输出后果会直接传导到真实系统里。我把它设计成类似“安检门”的模式——每个工具调用都要过一次安检门高危操作还需要额外人工确认。例如删除类工具、外发数据类工具默认都是拒绝状态只有特定会话里手动放行。3.3 状态管理层与安全校验层Harness架构的“记忆”和“刹车”状态管理层负责记录整个任务的当前状态对话历史、任务进度、临时变量、已完成的工具调用。没有这层记忆AI就只是无状态的接话机器人根本做不了跨多轮的复杂任务。我把状态做成可持久化结构任务中断后能恢复这是Harness架构跟普通脚本最大的区别。实现上我用的是一个全局状态对象支持序列化和快照回滚。某次任务跑了很长链条中途某一步参数错了我只需要回滚到上一个快照重新调整参数再跑不用整条链路推倒重来。这一点在长任务里的价值是决定性的。安全校验层则是我给自己留的“后悔药”。只要是AI生成的内容我默认不信任。输入侧会检查提示词注入输出侧会检查有没有异常内容执行侧所有高危操作统一走人工确认队列。这套机制在项目后期发挥了巨大作用因为我开始允许第三方集成调用部分工具后安全边界的压力一下就上来了。3.4 编排层把零散工具串成一条生产流程最后是编排层。它负责定义“模型在什么条件下调用哪个工具调用完怎么处理结果失败怎么重试”。我把它设计成声明式的工作流脚本用JSON描述即可不需要写代码去改逻辑。比如{ steps: [ {action: search_documents, on_success: summarize_result}, {action: summarize_result, on_failure: retry_once} ] }好处是调试方便出问题可以在编排文件里直接改不用重新构建整个服务。这个五层架构花了比较多的时间在前三层但后期开发效率也因此明显提升。每个模块的职责都非常清楚AI生成代码时只需要对准某一层不会陷入“不知道该改哪”的混乱。4. 九个月研发节奏一个人如何不掉链子4.1 三阶段规划与“关门标准”九个月我切成三段每段都有一个明确的关门标准不达标就砍功能不延后第1-3个月架构设计与核心骨架。目标是把上述五层架构跑通搭出一个可运行的MVP核心链路能端到端走通。第4-6个月功能密集开发。订阅计费、管理后台、第三方集成、前端页面都在这个阶段铺开。第7-9个月性能优化、兼容性修复、安全加固和发布准备。存量代码全面过一遍修掉各种边角问题。每段结束我复盘一次“数据指标”MVP阶段看链路通过率和单轮响应时延密集开发阶段看功能完成率和bug密度发布准备阶段看崩溃率和异常回放成功率。复盘时如果发现某项目标没到我会当场决定砍掉它而不是延后——因为九个月的时间盒是硬约束拖了第一阶段后面阶段都会连锁爆炸。4.2 每周一个“北极星目标”的进度法则一个人开发最大的敌人其实不是技术难题而是“每天都在忙月底一看啥也没落地”的虚无感。我用来对抗这个问题的方法很朴素每周只设一个“北极星目标”。比如第一周的北极星是“让X模型能稳定往返调用工具10次不报错”这一周所有每天的任务都围绕它展开。目标必须是可验证的不是“尽量稳定”而是“10次里面成功多少次有明确数字”。周中如果偏离目标我会立刻纠偏。我在代码仓库里还放了一个《WEEKLY.md》每周日晚上强制更新四行信息本周做了什么、数据指标、下周计划、风险项。别小看这四行它让我在第九个月回顾时能清楚看到每一个阶段到底做了什么哪周效率暴跌哪周出了严重事故。对单人项目来说这是最廉价又最高效的项目管理工具比任何看板软件都管用。4.3 时间账本1600小时做了什么有朋友问我20万行代码是怎么用时间堆出来的。我算过一笔账工作日晚上8点到凌晨2点周末两天各8到10小时按每周25到30小时计算九个月大概1600小时。这1600小时里真正手写代码的时间不到一半。我大部分时间花在架构决策、接口定义、代码评审和关键算法上。AI负责代码生成我负责“决定生成什么、怎么生成、生成之后要不要”。这种分工模式是AI辅助开发的正确姿势——不是让AI包办一切而是让AI当高效的执行者人当决策者。我自己最深的感受是代码量并不是衡量进度的可靠指标。AI能一小时写出几百行代码但真正该关心的指标是线上功能有多少是稳定可用的核心链路的故障率是多少用户遇到的问题能不能24小时内解决这几项比代码行数有意义得多。5. 常见问题与排查实录一个人debug靠什么兜底5.1 token过期与鉴权错误排查顺序九个月里遇到最多的一类“环境问题”其实是token鉴权错误。不管是登录应用、调用API还是刷新授权这类问题本质上都是OAuth/API鉴权故障。我总结了一套排查顺序遇到“token exchange failed”这类提示时逐项对照确认token是否还在有效期内。很多坑来自本地缓存了过期值代码没重新拉取。确认refresh_token是否为空或已经被消费过。刷新接口返回400 bad request最常见的元凶就是refresh_token为空字符串或者被并发请求重复消费。确认鉴权接口的日志里记录的报错码和状态码重点区分401和403的差异。区分HTTP状态码的语义401大概率是token过期403大概率是权限不足或业务规则拦截不要去改token先检查请求头和账号权限。我自己就在这块吃过大亏。有一次线上服务连续报错一小时排查半天才发现是refresh_token缓存逻辑写错了新拿到的刷新token覆盖了还在用的旧token导致所有并发请求都拿着同一个失效值去刷新。修复后我加了一条铁律任何鉴权模块都禁止修改正在使用的token对象必须先生成新token再切换引用。这话听着像常识但代码一复杂类飞了。5.2 AI生成“幻觉代码”的两道拦截闸门AI用久了一定会遇到它一本正经地调用一个根本不存在的库函数或者导入一个不存在的模块。这种幻觉代码如果直接进生产环境轻则运行时报错重则数据错乱。我的拦截方式分两道第一道是编译和类型检查。生成代码后立即跑类型检查大部分幻觉API会被直接拦下来。Python本身是动态语言类型检查的效果弱一些但也能挡掉“属性不存在”这类低级问题。如果是强类型语言这道闸门的效率会更高。第二道是强制AI为自己生成的代码写单元测试。这一步很有用——如果AI自己生成的测试也引用了同一个幻觉函数测试执行时会直接暴露问题。这个机制把“看起来能跑”变成“跑起来验证过”。还有一个小技巧如果运行时报“某某模块找不到”优先怀疑不是环境问题而是AI把“子虚乌有”的库当成了标准库。这时候把当前项目真实的模块列表发给AI让它重新生成导入部分往往比折腾环境配置快得多。5.3 那个最贵的三周重构九个月里唯一一次让我感觉“撑不下去”的时刻是第五个月的一次大重构。当时早期模型接入层用的是同步调用到了功能密集期并发一上来就卡死。没办法只能把模型接入层全面改成异步。这次重构前后花了三周调用链遍布整个系统改到后面我一度想推倒重来。后来是怎么走出来的我把模块依赖图画在一张白板上每天只改一条链路每条链路改完跑一遍全量测试然后坐回去复盘全局。AI在这个过程中帮我完成了大量机械性的变更但架构决策和影响面分析始终是我自己做的。这次重构留下的经验很直接涉及全局架构的改动AI只能做执行者不能做决策者。重构前先把依赖关系梳理清楚画一张真实的依赖图比让AI直接动手改靠谱得多。依赖图就是你在重构里的地图手上有地图AI作为“施工队”才不会把墙拆歪。6. 最后分享一点我的真实体会6.1 对AI辅助开发的新认知九个月做下来我对AI辅助开发有了跟刚开始完全不同的看法。最初我以为AI能帮我写代码后来发现它更像一个“超高效率的初级工程师”——你给它清晰的任务它能快速产出但什么是好架构、什么逻辑要保留、什么模块要砍掉这些判断必须由人来完成。这种“AI当执行者、人当决策者”的模式听起来很简单执行起来却很考验人的自控力。因为AI产出太快了你很容易陷入“让它继续写、写完再说”的惯性结果代码库膨胀技术债爆炸。我后期专门给自己定了一条规矩AI生成的代码必须经过评审和测试才能合入主干绝不允许为了省事跳过。6.2 三个值得坚持的习惯如果你想用类似方式做独立项目我的建议是第一小目标起步。不要一开始就把目标定成20万行代码先定一个“让AI帮我把最难的核心链路跑通”的小目标然后一层一层往上加。第二token预算一定要提前规划。不是不花钱而是把每一分花在刀刃上。上下文管理一定要抠细节该断舍离就断舍离不要图省事把一大堆无关代码塞给AI。第三AI生成代码一定要过校验和测试。任何跳过验证的效率提升都会在后期用更大的返工成本还回来。我始终觉得Harness架构的核心其实不是那五层代码框架而是一套“人和AI协作的安全边界”。你给AI多大的自由度决定了它能跑多快但你为这个自由度设了多少约束决定了项目能活多久。这句话算是我这九个月最值钱的总结。
一个人九个月20万行代码：AI辅助开发实战与Harness架构落地
一个人、九个月、20万行代码、每个月烧掉40亿 token——这些数字放在一起外人可能会以为是一个小团队在冲刺但确实是一个人在造一款Harness架构应用时的真实账单。不是标题党也不是段子而是我过去九个月的真实节奏白天写设计、晚上喂AI、周末重构月均tokens消耗稳定在40亿以上。今天把这九个月的思路、踩坑和数据整理出来对想用AI辅助独立开发的朋友应该有点参考价值。先回答大家最关心的问题这款Harness架构应用到底做什么简单来说它是一套面向AI工作流的执行框架把模型调用、工具执行、状态管理和安全校验封装成可插拔的层让AI能力可以稳定地接入业务场景。说白了就是给AI这匹烈马套上马具让它既能跑得快又不会脱缰。1. 先交代背景为什么一个人敢碰Harness架构1.1 一句话说清Harness架构好多朋友第一次听到“Harness架构”都问同一个问题这东西跟微服务、事件驱动有什么区别是不是又一个造出来的概念我的回答是Harness架构不是全新的架构范式而是一种专门为AI应用设计的代码组织方式。它把应用拆成五层——模型接入层、工具执行层、状态管理层、安全校验层、编排层每层有清晰边界层与层之间只通过接口通信。这样做的直接好处是AI生成代码时只要约定好每层的接口它就能按模板填代码不大会出现“生成一个函数结果它顺手改了别的模块”的情况。Harness这个词的英文原意是“马具”。烈马有跨越复杂任务的潜力但能不能安全地骑上去、控制方向取决于缰绳、马鞍设计得好不好。Harness架构就是那副马具它不提供模型能力但决定了模型能力能不能被稳定地、安全地用起来。我见过太多AI应用模型效果好得一塌糊涂一接进生产环境就崩原因不在模型而在承载模型的这套“鞍具”做得太粗糙。这个概念本身不是学术定义更像是我在实践里总结的工程经验。对个人开发者来说它的价值在于把“让AI做事”变成“让AI在我划定的安全区内做事”这对后续九个月批量产代码至关重要。1.2 为什么一个人花九个月做这个很多人听到“一个人20万行代码九个月”会觉得我疯了。为什么不先做个简单的小工具跑通一个需求再慢慢迭代其实这个选择背后有三层考虑。第一AI应用正在快速从“单一模型调用”走向“多工具编排”。真正卡住应用的往往不是模型效果而是“代码架构扛不住复杂AI交互”。市面上的重框架适合团队轻框架只适合做Demo中间恰好空出一块“个人开发者用得上、又愿意接受低成本”的地带。我想填的就是这个空档。第二单人开发最大的优势是决策链路短。架构上任何地方不顺眼我可以当天就暴力重构不需要说服同事。团队里常见的“架构演进需要评审”在这里完全不成立。九个月里我确实重构了好几次每次都是说改就改这是我敢碰重架构的底气。第三我想真实验证一件事在AI辅助编程已经足够成熟的今天一个人到底能不能在九个月内交付一个团队级别复杂度的产品。结论是可以但前提是——你得有意识地管理token、管理上下文、管理AI产出代码的质量而不是把AI当无限生成器。2. AI辅助开发20万行代码是怎么和AI“结对”写完的2.1 每个月的token账单到底花在哪先放数据。不含闲聊和实验性调用我每个月的token消耗大致分成四块用途占比月消耗量约说明代码生成55%-60%22亿-24亿新功能、单元测试、配置、脚手架重构与解释20%-25%8亿-10亿存量代码梳理、性能优化、跨模块问题定位调试与排错10%-15%4亿-6亿分析日志、堆栈、让AI解释报错原因文档与设计5%-10%2亿-4亿架构文档、README、注释、API说明按通用token计数规则1个token大约对应0.75个英文单词。40亿token粗略折算就是30亿个单词平均每天一亿多个token输入到模型API里。这大概是我这个项目最大的一笔运行成本也是很多人听到数字就会被吓住的地方。好在我消耗的不是一次性算力而是有效产出。代码生成部分真正落进仓库的比例前三个月只有三成左右到后面稳定在六到七成——这说明AI辅助开发的效率很大程度取决于你怎么提需求而不只取决于模型有多强。2.2 我拆任务的“代码原子化”方法20万行代码如果指望AI一句话生成结果大概率是一堆让人崩溃的垃圾。我摸索出一套叫“代码原子化”的拆解方法把一个完整功能不断向下拆拆到每个任务足够小小到AI能稳定输出一个高内聚的文件或者函数。一个“代码原子”的典型特征单个文件最多不超过200行只有一个核心职责名字里就说得清输入输出类型在任务描述里提前定义好不允许AI自由发挥依赖的外部接口在上下文里给全不存在的模块绝不引入拆解的起点是架构图。我先把系统拆成模块再拆服务再拆函数最后才算“可以交给AI的最小单元”。这一步看起来多花时间但实际上是在替AI降低出错的概率。实测下来直接让AI写一个20行函数成功率高到离谱让AI直接写一个完整业务模块则大概率要返工两三轮。举个例子早期我做后台的订阅计费模块让AI一口气生成“创建订单校验套餐扣费生成发票”整个链路的代码改了四遍才勉强通过。后来我把它拆成“校验套餐”“检查余额”“扣费”“生成发票”四个原子任务每个任务单独交付总耗时反而只有原来的三分之一。2.3 四段式提示词模板和上下文“断舍离”同样的模型同样的量级用不同的描述方式AI产出质量能差三倍以上。我固定下来的模板是四段式【任务】你要实现什么功能做到什么程度 【约束】不能用什么必须遵守什么项目规范 【示例】给出输入输出的具体样例 【验收】代码满足什么标准才算通过模板本身不神奇神奇的是“强制AI按模板走”这个动作。它把模糊的开发意图变成了可校验的交付标准返工率肉眼可见地下降。比如写一个接口服务任务描述里如果不写“输入参数必须是字符串非法输入返回400”AI很可能自己发明一套异常处理逻辑返回的格式跟全局协议对不上。上下文管理是我控制token成本的关键。刚开始我走过一个弯路把整个项目的说明文档、接口定义、所有相关代码全部都塞进上下文生怕AI信息不足。结果token爆炸而且模型处理长上下文时注意力会被稀释垃圾代码反而变多。后来我改成了“按模块开独立会话”每个会话只携带当前模块的接口定义、关键代码片段和少量示例每次对话快结束时让AI生成一段精简的摘要把它存到临时文件。下次继续时只需要把摘要灌回上下文。实测下来这种“上下文断舍离”让单次任务成本下降了将近40%代码质量反而更稳定。3. Harness架构落地五个关键层的设计与实现3.1 模型接入层为多模型切换留好后路Harness架构的最底层是模型接入层核心是一个叫ModelPort的抽象接口from abc import ABC, abstractmethod from typing import Any class ModelPort(ABC): abstractmethod async def chat(self, messages: list[dict], tools: list[dict] | None None) - dict: 统一对话入口 abstractmethod async def stream_chat(self, messages: list[dict], tools: list[dict] | None None): 流式对话供需要持续输出的场景使用所有模型实现都实现这个接口业务代码永远只依赖ModelPort不关心底层是哪个模型。这块最大的难点不是模型能力的高低而是协议差异有的模型有function calling能力有的没有有的支持流式返回有的不支持有的参数命名还不一样。我在接入层里统一把这些差异拦掉业务侧看到的永远是同一种消息格式后面加新模型时业务代码不需要跟着动。这个设计在最开始显得有点“过度设计”一上来就搞抽象。到了第七个月我要接入第二个模型做路由备份时发现它值回了票价只改一个配置文件新增一个实现类业务代码一行没动。如果你也在做AI相关应用别嫌接口抽象麻烦多花半天定义一个稳定的模型入口后面能省好几个通宵。3.2 工具执行层让AI“动手”之前先过三关工具执行层是Harness架构里最重的一层。它解决的核心问题是当模型说“我想调用某个函数”时系统怎么安全、可控地让这个调用真正发生。我的实现是“注册表沙箱”的组合。每个对外能力都注册成一个带schema描述的工具tool(search_documents, description搜索本地文档库) async def search_documents(query: str, top_k: int 5) - list[Document]: ...工具执行之前我一定会做三层检查参数类型校验模型给出来的参数类型对不对、值是否在合法范围内资源权限校验这个工具在当前会话里是否有权限被调用返回值容量校验返回值会不会太大撑爆后续流程没有这三层检查模型一旦产生幻觉输出后果会直接传导到真实系统里。我把它设计成类似“安检门”的模式——每个工具调用都要过一次安检门高危操作还需要额外人工确认。例如删除类工具、外发数据类工具默认都是拒绝状态只有特定会话里手动放行。3.3 状态管理层与安全校验层Harness架构的“记忆”和“刹车”状态管理层负责记录整个任务的当前状态对话历史、任务进度、临时变量、已完成的工具调用。没有这层记忆AI就只是无状态的接话机器人根本做不了跨多轮的复杂任务。我把状态做成可持久化结构任务中断后能恢复这是Harness架构跟普通脚本最大的区别。实现上我用的是一个全局状态对象支持序列化和快照回滚。某次任务跑了很长链条中途某一步参数错了我只需要回滚到上一个快照重新调整参数再跑不用整条链路推倒重来。这一点在长任务里的价值是决定性的。安全校验层则是我给自己留的“后悔药”。只要是AI生成的内容我默认不信任。输入侧会检查提示词注入输出侧会检查有没有异常内容执行侧所有高危操作统一走人工确认队列。这套机制在项目后期发挥了巨大作用因为我开始允许第三方集成调用部分工具后安全边界的压力一下就上来了。3.4 编排层把零散工具串成一条生产流程最后是编排层。它负责定义“模型在什么条件下调用哪个工具调用完怎么处理结果失败怎么重试”。我把它设计成声明式的工作流脚本用JSON描述即可不需要写代码去改逻辑。比如{ steps: [ {action: search_documents, on_success: summarize_result}, {action: summarize_result, on_failure: retry_once} ] }好处是调试方便出问题可以在编排文件里直接改不用重新构建整个服务。这个五层架构花了比较多的时间在前三层但后期开发效率也因此明显提升。每个模块的职责都非常清楚AI生成代码时只需要对准某一层不会陷入“不知道该改哪”的混乱。4. 九个月研发节奏一个人如何不掉链子4.1 三阶段规划与“关门标准”九个月我切成三段每段都有一个明确的关门标准不达标就砍功能不延后第1-3个月架构设计与核心骨架。目标是把上述五层架构跑通搭出一个可运行的MVP核心链路能端到端走通。第4-6个月功能密集开发。订阅计费、管理后台、第三方集成、前端页面都在这个阶段铺开。第7-9个月性能优化、兼容性修复、安全加固和发布准备。存量代码全面过一遍修掉各种边角问题。每段结束我复盘一次“数据指标”MVP阶段看链路通过率和单轮响应时延密集开发阶段看功能完成率和bug密度发布准备阶段看崩溃率和异常回放成功率。复盘时如果发现某项目标没到我会当场决定砍掉它而不是延后——因为九个月的时间盒是硬约束拖了第一阶段后面阶段都会连锁爆炸。4.2 每周一个“北极星目标”的进度法则一个人开发最大的敌人其实不是技术难题而是“每天都在忙月底一看啥也没落地”的虚无感。我用来对抗这个问题的方法很朴素每周只设一个“北极星目标”。比如第一周的北极星是“让X模型能稳定往返调用工具10次不报错”这一周所有每天的任务都围绕它展开。目标必须是可验证的不是“尽量稳定”而是“10次里面成功多少次有明确数字”。周中如果偏离目标我会立刻纠偏。我在代码仓库里还放了一个《WEEKLY.md》每周日晚上强制更新四行信息本周做了什么、数据指标、下周计划、风险项。别小看这四行它让我在第九个月回顾时能清楚看到每一个阶段到底做了什么哪周效率暴跌哪周出了严重事故。对单人项目来说这是最廉价又最高效的项目管理工具比任何看板软件都管用。4.3 时间账本1600小时做了什么有朋友问我20万行代码是怎么用时间堆出来的。我算过一笔账工作日晚上8点到凌晨2点周末两天各8到10小时按每周25到30小时计算九个月大概1600小时。这1600小时里真正手写代码的时间不到一半。我大部分时间花在架构决策、接口定义、代码评审和关键算法上。AI负责代码生成我负责“决定生成什么、怎么生成、生成之后要不要”。这种分工模式是AI辅助开发的正确姿势——不是让AI包办一切而是让AI当高效的执行者人当决策者。我自己最深的感受是代码量并不是衡量进度的可靠指标。AI能一小时写出几百行代码但真正该关心的指标是线上功能有多少是稳定可用的核心链路的故障率是多少用户遇到的问题能不能24小时内解决这几项比代码行数有意义得多。5. 常见问题与排查实录一个人debug靠什么兜底5.1 token过期与鉴权错误排查顺序九个月里遇到最多的一类“环境问题”其实是token鉴权错误。不管是登录应用、调用API还是刷新授权这类问题本质上都是OAuth/API鉴权故障。我总结了一套排查顺序遇到“token exchange failed”这类提示时逐项对照确认token是否还在有效期内。很多坑来自本地缓存了过期值代码没重新拉取。确认refresh_token是否为空或已经被消费过。刷新接口返回400 bad request最常见的元凶就是refresh_token为空字符串或者被并发请求重复消费。确认鉴权接口的日志里记录的报错码和状态码重点区分401和403的差异。区分HTTP状态码的语义401大概率是token过期403大概率是权限不足或业务规则拦截不要去改token先检查请求头和账号权限。我自己就在这块吃过大亏。有一次线上服务连续报错一小时排查半天才发现是refresh_token缓存逻辑写错了新拿到的刷新token覆盖了还在用的旧token导致所有并发请求都拿着同一个失效值去刷新。修复后我加了一条铁律任何鉴权模块都禁止修改正在使用的token对象必须先生成新token再切换引用。这话听着像常识但代码一复杂类飞了。5.2 AI生成“幻觉代码”的两道拦截闸门AI用久了一定会遇到它一本正经地调用一个根本不存在的库函数或者导入一个不存在的模块。这种幻觉代码如果直接进生产环境轻则运行时报错重则数据错乱。我的拦截方式分两道第一道是编译和类型检查。生成代码后立即跑类型检查大部分幻觉API会被直接拦下来。Python本身是动态语言类型检查的效果弱一些但也能挡掉“属性不存在”这类低级问题。如果是强类型语言这道闸门的效率会更高。第二道是强制AI为自己生成的代码写单元测试。这一步很有用——如果AI自己生成的测试也引用了同一个幻觉函数测试执行时会直接暴露问题。这个机制把“看起来能跑”变成“跑起来验证过”。还有一个小技巧如果运行时报“某某模块找不到”优先怀疑不是环境问题而是AI把“子虚乌有”的库当成了标准库。这时候把当前项目真实的模块列表发给AI让它重新生成导入部分往往比折腾环境配置快得多。5.3 那个最贵的三周重构九个月里唯一一次让我感觉“撑不下去”的时刻是第五个月的一次大重构。当时早期模型接入层用的是同步调用到了功能密集期并发一上来就卡死。没办法只能把模型接入层全面改成异步。这次重构前后花了三周调用链遍布整个系统改到后面我一度想推倒重来。后来是怎么走出来的我把模块依赖图画在一张白板上每天只改一条链路每条链路改完跑一遍全量测试然后坐回去复盘全局。AI在这个过程中帮我完成了大量机械性的变更但架构决策和影响面分析始终是我自己做的。这次重构留下的经验很直接涉及全局架构的改动AI只能做执行者不能做决策者。重构前先把依赖关系梳理清楚画一张真实的依赖图比让AI直接动手改靠谱得多。依赖图就是你在重构里的地图手上有地图AI作为“施工队”才不会把墙拆歪。6. 最后分享一点我的真实体会6.1 对AI辅助开发的新认知九个月做下来我对AI辅助开发有了跟刚开始完全不同的看法。最初我以为AI能帮我写代码后来发现它更像一个“超高效率的初级工程师”——你给它清晰的任务它能快速产出但什么是好架构、什么逻辑要保留、什么模块要砍掉这些判断必须由人来完成。这种“AI当执行者、人当决策者”的模式听起来很简单执行起来却很考验人的自控力。因为AI产出太快了你很容易陷入“让它继续写、写完再说”的惯性结果代码库膨胀技术债爆炸。我后期专门给自己定了一条规矩AI生成的代码必须经过评审和测试才能合入主干绝不允许为了省事跳过。6.2 三个值得坚持的习惯如果你想用类似方式做独立项目我的建议是第一小目标起步。不要一开始就把目标定成20万行代码先定一个“让AI帮我把最难的核心链路跑通”的小目标然后一层一层往上加。第二token预算一定要提前规划。不是不花钱而是把每一分花在刀刃上。上下文管理一定要抠细节该断舍离就断舍离不要图省事把一大堆无关代码塞给AI。第三AI生成代码一定要过校验和测试。任何跳过验证的效率提升都会在后期用更大的返工成本还回来。我始终觉得Harness架构的核心其实不是那五层代码框架而是一套“人和AI协作的安全边界”。你给AI多大的自由度决定了它能跑多快但你为这个自由度设了多少约束决定了项目能活多久。这句话算是我这九个月最值钱的总结。
