北京
我的时间只有20%花在写代码上。剩下的80%都在处理需求审核、任务拆分、质量把关和部署决策——这些听起来很“研发”的事情，实际上由一个没有计算机学位、做市场推广出身的人操盘。我不是软件工程师，但现在做的很多东西都在靠工程流程来运转。
这个转变从一份认知开始：编程和工程是两码事。编程是写代码，工程是决定哪些代码该写、写完后怎么验证、谁来确认、什么时候可以上线。把这两者分开之后，非技术人员也能用上工程的方法来管理技术产出。
流程比模型更重要，这是我从实际项目中得出的结论。我现在用 Linear 管理所有在推进的事情，不管是增长工作流、内部工具还是给客户做的定制功能，都走同一套流水线：Backlog → Todo → In Progress → Review → Done。每个环节之间的交接都不是靠“我觉得可以了”这种主观判断，而是有明确的执行代理和审核代理在承担角色。
当一个任务被标记为“就绪”，会有一个编排代理拉起来：一个代理负责构建实现，另一个负责审查代码，第三个只在前一个明确批准时执行部署。重要的不是用了三个代理，而是每个阶段都把推理过程留了下来。每次交接都变成 Linear 里的一条评论，说清楚改了什么、测了什么、还有哪些风险点。这样一来，工单本身就变成了一条审计轨迹。这套机制彻底改变了我做事的方式，也逼着我必须把一切拆成很小的、可以独立验证的任务。
这里有一个很多人忽略的分工：前沿模型应该用来做决策，而不是干体力活。我把需要判断力的工作交给人或者最强的模型：编排逻辑、架构决策、代码审查、业务规则设计，这些场景要的是“想清楚”而不是“跑得快”。而大批量的标准化任务——比如数据补全、分类、爬取、高并发的调用——全都放到开放模型上去处理，这类工作不需要前沿智能，需要的是吞吐量和性价比。把这个分工跑通之后，我甚至撤掉了一个付费搜索API，因为代理自己就能完成同类的发现任务。
在没有写第一行代码之前，我逼着自己“把想法烤一遍”。这个习惯几乎是从 Matt Pocock 的工作流里直接搬过来的：先用 /grill-me 把每个假设都推敲一遍，找出遗漏的需求、边缘情况和逻辑矛盾，直到确认没有死角；然后再用 /to-prd 把讨论转成正式的规格说明，以清单的形式发布成 Linear 里的实施任务。等到代理开始写代码时，拿到的不是一段模糊的提示词，而是一份完整的文档。
清单这种方式对LLM来说特别好使——它强制模型不能跳过任何步骤。坦白讲，这一步对质量的提升，比换更贵的模型都来得明显。因为模型再强，如果被丢进一个定义不清的任务里，也会产出定义不清的结果。
还有一个被低估的基建：上下文。我慢慢意识到，提示词本身没那么重要，质量的大头来自系统预先加载的上下文。我把业务里所有重要的东西都放进仓库里，用 CLAUDE.md 记录业务规则、架构说明和参考文档。每次新会话启动时，这些上下文已经加载好了，精简而且按需调用。这相当于每次我给代理“入职”时，不用再反复解释我的业务是做什么的，就像给新同事发一份核心资料一样。这件事的本质，是把隐性知识从人脑里抽出来，变成机器可读的结构化信息。
回到一个经常被争论的问题：非技术人员到底要不要学这些工程流程？有一种观点是，搞市场、做增长的人把业务执行好就够了，掺和这些工程方法是徒增复杂度。但我的实际体验是，如果没有这套流程，任务的状态全在聊天记录和脑子里，一到多个任务并行就乱套，出错之后也很难追溯哪一环出了问题。工程流程不是增加了负担，而是把原本隐性的协作成本变得可见、可管理。
所以关键在于想清楚一点：你缺的不是写代码的能力，而是定义“什么是做完”的能力。把想法拆成任务、用代理去执行、用审核保证质量、用清单防止遗漏，这些是任何想把事情做扎实的人都可以借鉴的东西。写不写代码只是手段，工程流程才会让你从小作坊式的产出，过渡到有质量保证的交付体系。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
