2. Linux.do
  3. 想和做研发的兄弟聊聊 vibe coding（所谓的能跑好几天的 agent）

想和做研发的兄弟聊聊 vibe coding（所谓的能跑好几天的 agent）

人生何处不青山 2026-07-10 23:43 1

所以最近好多技术群里都在说用什么 skills，用什么提示词，通过 Codex 或者什么 Agent 的goal 的方式基于一个简短的需求，去持续运行好多天的截图。


“所谓的一句话生成一个系统”


我觉得所谓一个任务跑好多天"意义不大"，或者说是受众范围不广。


从软件工程的角度来讲我是希望需要在每个里程碑进行验收的（ 准确的说我反对缺少阶段性反馈、验收的长时间自主执行）。确认阶段性结果是否符合预期，再决定是否继续推进、调整，或者直接回滚。


一个任务如果连续运行很多天，却没有中间产物和人工介入点，本质上就是一个不可观测、不可控制的黑盒，那么，如果有一点偏离预期，那么在错误的道路上则会越走越远。即使"看似可行"，未来也是要还的技术债。


实际上长任务中间还涉及到压缩上下文从而导致细节丢失的问题。


真正有价值的，不是让 Agent 持续运行多长时间，而是它能否把一个复杂目标拆解成若干可验证的阶段，在每个阶段输出明确结果，并保留上下文、执行记录、失败原因和恢复能力(那么对于 vibe coding 来说，实际上它是不会失败的，（基于当前的顶级模型来说，一般来说它都可以生成一个看似 OK 的代码。那么，对于他失败的特征来说，就是偏离了我的架构预期和业务预期 )。


这样即使任务跨越数天，也不是单个进程从头跑到尾，而是由多个相对独立、可重试、可审计的工作单元组成。


所以在 vibe coding场景我更关心的是：任务拆解是否合理（上下文是否触发自动压缩），阶段结果是否可验收以及人工能否随时介入。至于“连续跑了多少小时、多少天”，更像是一个演示指标，而不是我的"编程助手"的核心指标。


所以我理想的情况是： 基于需求生成task，每个 task 尽可能不会触发自动的上下文压缩(如gpt 256k、353k，甚至是尽可能不到其 80%(我觉得大于 80 之后就不靠谱了^-^))。


以上是我的想法，想和何为佬友聊一下～

最新回复 (7)
  • 洛卡卡了 07-10 23:45
    1楼

    还是分情况的，有些是可以直接 vibe coding 的 有些是需要 spec coding 的，只是建议都按照标准的 spec coding 来开发罢了，但是现在的情况，如果是个人项目的话，也没必要复杂化，变现才是第一位的，所以求快就不要求那么多了。

  • 厉飞雨与羽 07-10 23:46
    2楼

    我觉得像codex的上下文长度别说跑几天了,执行半晌怕不是都要忘了开头的内容了

  • 咕嘎治愈世界 07-10 23:50
    3楼

    AI生成的内容需要截图发送，不然回头要被人炼化了。

    这正文八股的味道很重，ai润色的。


    另一方面一句话ai跑几天不是不不行，实际很难实现你想要的东西。


    打开淘宝，帮我把整个淘宝支付宝抄一套

    这种需求跑几天，跟你诉求又不一致。 说的玄乎，其实重点在使用ai完成你的需求，不用过度追求一次跑多久，跑多少token。关键在结果，这些都是过程。熟练之后再想办法减少人工干预次数，提升效率。


    AI会自动压缩上下文，实测开发的事后多次压缩也不会影响最终结果。细致程度肯定不能跟每次对话的上下文比。超长之后产生幻觉几乎是必然的

  • hoofa 07-10 23:52
    4楼

    一开始就把基准定好，各模块边界分好。然后生成需求文档/开发文档。都审过了再编码，然后再让ai自己对一下需求跑一下冒烟测试。就不会偏差太大了。和现实中开发一样，都是多个团队共同开发最后合成一个大项目。

  • 越笑越见疤痕 07-11 00:00
    5楼

    实践中我觉得无关上下文，如果使用gpt5.5这种可靠性高的模型， 能否长期稳定运行只跟系统整体复杂度和是否存在可靠实现路径有关。 复杂度体现在需求的数量、描述是否准确清晰、边界条件是否有明确的约束、是否存在清晰的验收标准等。 可靠的实现路径指的是每个迭代的反馈的交付物是否被明确跟踪记录。


    换句话说， 目标系统可能有 N 个需求， 但是开发者需要从 1-> N摸石头过河，系统复杂度高且需要边开发边探索，这个时候就适合做短周期快速迭代来快速获取反馈循环。 相反，如果开发者对每个迭代的输入和交付物都充分了解（例如代码重构、换一种语言洗别人的项目或者已经实现过一遍），有足够的知识库已经记录了可实现路径， 这样的话就可以直接跑长任务。但是也不是“一句话”可以驱动的，必须有可靠的信息源来支撑。

  • tito1 07-11 00:05
    6楼

    同意，从这种角度，我认为gpt走错路了，在5.6他把无限执行作为了一个突破点。然而我并没有看出他聪明在哪里。

  • Enze 07-11 00:18
    7楼

    基于一个简短的需求，去持续运行好多天



    现阶段这种许愿式的确实不值得作为参考，我们不讨论 ^-^



    需要在每个里程碑进行验收



    这也是 agent 对长任务的设计理念之一啊，无论是 Anthropic[1] 还是 OpenAI[2] 都是这样，甚至对/goal的描述就是clear success condition and validation loop



    如果有一点偏离预期，那么在错误的道路上则会越走越远




    “看似可行”，未来也是要还的技术债



    根据我的经验，能全部交给 agent 的可能也不会在意技术债，项目规模也不会太大，甚至项目存在的时间也不会很久，要的可能只是快和能跑就行


    你描述的理想情况是我不得不面对的现实，你不期望的反而是我想要的理想情况 ^-^我觉得业界应该也都是在朝着这个方向努力吧





    1. Effective harnesses for long-running agents \ Anthropic ↩︎



    2. codex/codex-rs/ext/goal/templates/goals/continuation.md at 2b9c05046038c038ec6bddb9db7d11394995372d · openai/codex · GitHub ↩︎



* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐