Hacker News上有人发帖询问大家是否在尝试用不同方式将大语言模型用于编程，引发讨论。

好的，这是对原文主要内容的重新陈述，已保留关键细节并删减了与主题无关的冗余内容。

核心问题： 一位开发者（yehiaabdelm）在Hacker News上提问，他感觉目前使用大语言模型（LLM）进行编程的方式陷入了僵局。他使用Claude Code和Codex等工具，但无法像手写代码时那样进入“心流状态”。他认为AI本应是思维的“自行车”，但现在却像一辆每隔几分钟就突然刹车的自行车，需要不断停下来、等待、审查、再提示。他询问是否有人在探索与当前“提示-响应”循环根本不同的新方法，并认为“标签页模型”（tab model）在方向上优于“提示-响应”模式。

社区回复中的主要实验方向与观点：

1. 从“手动提示”转向“自主工作流”：

   • 提前规划，批量执行： 多位用户（如chris_fullcycle, pigpop）分享，关键在于提前进行详尽的规划（如编写PRD、UI规范、详细设计文档），然后将整个任务交给LLM（如Claude Code）自主执行，甚至允许其自动批准命令，在后台通宵工作。这样，开发者只需在规划阶段和最终审查阶段保持专注，避免了执行过程中的频繁中断。
   • “管理者”而非“开发者”角色： 许多用户（如notahan, magicmadrid00）指出，使用LLM编程后，角色从“开发者”转变为“管理者”。工作重心变为编写清晰的需求、审查生成的代码，而不是逐行编写代码。这虽然改变了工作方式，但可能更高效。

2. 构建多智能体（Multi-Agent）系统：

   • 隔离与对抗： 用户seanmcdirmid提出了“隔离智能体”的概念。例如，一个智能体负责写代码，另一个负责写测试，两者互不可见，以避免“确认偏误”。通过这种对抗性设计来提高代码质量。
   • 分工与协作： 用户leetrout和kosolam等尝试让不同智能体（如应用智能体、基础设施智能体）相互通信、协商，甚至发明自己的协作流程。用户vitally3643则利用家中闲置的GPU组建了一个异构LLM“蜂群”，让不同模型对同一任务进行“辩论”并综合意见，发现这在获取多样化观点方面效果惊人。
   • 图式工作流： 用户aleqs和fractorial正在开发基于图（DAG）的工作流执行引擎。任务被分解为节点，由“规划器”节点动态调整任务图，实现任务的分解、分发和并行执行。

3. 改进交互模式与工具：

   • “结对编程”模式： 用户philbo正在开发一个名为opair的工具，旨在模拟结对编程，具备“驾驶员”和“导航员”两种模式，可以快速切换，让开发者保持主导地位。
   • “行走编程”： 用户anthonyfrisby分享了一种“行走编程”的方法，即通过手机上的Telegram与LLM交互，在散步时进行编程，从而保持专注并避免无聊。
   • “自动补全”的进化： 用户colinmarc提到Zed编辑器的“编辑补全”功能，它像高级的Tab补全，能根据上下文预测光标附近的编辑，感觉更像一个“工艺枪”，比聊天机器人更流畅。
   • “反向”提示： 用户redmattred提出让智能体根据任务列表和用户的不同“角色”来主动向用户提问，从而将用户置于“响应”端，进入心流。

4. 对“心流状态”的反思：

   • 心流的本质： 用户avilay深入探讨了心流状态，认为其关键在于任务的难度恰到好处，能让人完全沉浸。使用LLM时，频繁的等待和中断破坏了这种沉浸感。
   • 新的心流形式： 一些用户（如tombot, codybontecou）认为，新的心流状态可能不再是手写代码，而是同时管理多个LLM会话，在多个任务间快速切换，像“鲍比·费舍尔同时下10盘棋”一样。
   • 认知参与度： 用户captainbland指出，与LLM交互相对被动，缺乏高强度的认知参与，这是难以进入心流的主要原因。这种被动性可能导致开发者对代码的理解不足，增加引入错误的风险。

总结： 社区普遍认为，当前“提示-响应”的交互模式是破坏心流状态的主要障碍。大家正在探索的解决方案包括：将工作重心从“写代码”转移到“写规范和审查”、构建多智能体协作系统、改进交互工具以模拟更自然的编程体验，以及重新定义在AI辅助下的“心流”状态。核心目标是减少不必要的等待和中断，让开发者能更专注于高层次的思考和决策。

根据评论内容，总结主要观点如下：

1. 减少外部编排，聚焦清晰规格（评分：None） - 核心观点：信任模型自身能力，减少外部编排，将精力放在提供清晰的规格上。 - 关键引用： - "focus your energy on providing clearer specs... focus on that and get out of the models way."（Jimmc414） - "don't give it an objective that is vague, give it clear exit criterias for goals and let it loop until it gets there"（Jimmc414）

2. 技能（Skills）比代理（Agents）更重要（评分：None） - 核心观点：技能能提升模型能力，代理主要用于上下文保存，技能才是能力提升的关键。 - 关键引用： - "skills on the other hand are very undervalued... agents are really for context preservation. skills are what increase capabilities"（Jimmc414） - "skills expand capabilities, agents constrain context"（Jimmc414）

3. 工作流与工具创新（评分：None） - 核心观点：开发者正在构建各种自定义工具和流程，如JSX模板语言、Sandcastle项目、工作箱等，以优化AI辅助开发。 - 关键引用： - "I’m writing a JSX templating language — to manage context, branching, etc automatically."（zmgsabst） - "I'm currently rolling out Matt Pocock's Sandcastle project... grilling into a spec and extract issues."（Bossie）

4. 流程状态与人类瓶颈（评分：None） - 核心观点：AI辅助开发难以进入流程状态，人类理解代码成为新瓶颈，需调整工作方式。 - 关键引用： - "the bottleneck has shifted even more dramatically to human code understanding vs code generation."（kybernetikos） - "Not being able to enter flow state is a very interesting observation."（avilay）

5. 控制权与自主性平衡（评分：None） - 核心观点：部分开发者偏好保持控制，手动编码核心部分，仅将琐碎任务委托给AI；另一些则追求更高自主性。 - 关键引用： - "I'll ask Claude for advice if I get stuck... I obstinately decline... Eventually, I'll get bored... at which point I'll ask Claude to complete just that part."（avilay） - "I'm trying to do the same amount of work faster, not do work in parallel or agent orchestration."（yehiaabdelm）

6. 未来方向：更智能的编排与团队协作（评分：None） - 核心观点：未来不在于更智能的模型，而在于如何让模型更有效，AI团队协作能带来最佳结果。 - 关键引用： - "I don't think the next step is really smarter models. It's how we make the models more effective, and teams, when done right, net the best results I've seen."（integrii） - "The key is to control behavior with what integrations and responsibilities each agent has."（integrii）

7. 安全与沙箱（评分：None） - 核心观点：使用AI代理时需注意安全，构建沙箱工具限制其权限。 - 关键引用： - "FLAR is the Fast Light Agent Restrictor. It bubblewraps an agent so it is quite safe to use agents on your local machine."（SwellJoe） - "I always put agents in VMs because I don't trust them."（SwellJoe）