加载失败
这是对一篇以“我做不到（I Can't Do That, Dave）”为题的文章与其评论的汇总反应，原文风格接近社交平台（如 LinkedIn）那类碎片化论述。讨论围绕三个主轴：读者对文章断裂写法的不满、LLM/agent 在实际任务中“拒绝”还是“应尝试并失败”的行为争议（涉及 ChatGPT、Claude（Anthropic 的模型）、Qwen（阿里巴巴系模型）的测试体验）、以及工程治理上的可行做法，例如在仓库里写 AGENTS.md、用 TECHNICAL_DEBT.md 跟踪债务并考虑将 LLM 输出版本化到 git（版本控制系统）。评论者普遍在意自动化如何与用户偏好、确认偏差和长期代码/设计质量权衡，且对可操作的实践步骤有明显分歧与怀疑。
多名评论者抱怨原文写作极为零碎、节奏断裂，读起来更像诗歌片段或社交平台上的断句而非清晰论证。有人直言引用与片段无法把观点连成一条可操作的主线，读者很难抓住作者的核心建议或结论。这种风格导致很多人直接放弃阅读，并用“AI slop”“poems”“Idiocracy”等词汇表达不满，质疑作者要传达的实际实践价值。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
讨论中出现强烈偏好：许多人宁可模型尝试并失败，也不愿看到不必要或错误的拒绝。具体例子包括 Qwen 在面对复杂项目时以“too complex”拒绝，以及 ChatGPT 曾短期内拒绝大段代码但在分步引导下能够完成任务，这些经验被用来说明拒绝行为既可能是合理的安全措施，也会成为阻碍。多位评论者建议：如果模型尝试失败，应明确报告失败并呈现最佳尝试，而不是草率拒绝或给出无用的答复。与此同时也有声音提醒必须区分保护性拒绝（政治、性/禁忌话题、药物等安全边界）和不合理的“false refusals”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
有评论指出用户更倾向接受通用-purpose agents，因为它们更容易迎合用户既有偏好，按用户习惯去自动化工作，从而加强确认偏差：‘按我想要的方式做’比被指出设计问题更受欢迎。专用 agents 若试图强加约束或更规范化的做法，往往不被用户接受，因为用户不愿面对错误或改变既有流程。评论还讨论到，这种偏好会牺牲利用通用知识与既定边界带来的长期收益；作为折中，一些人展示了让 agent 自我回顾并提出改进（例如评论中提到的“improvement engine”）的方法以减少手工干预。
多条评论提出具体工程实践：把 agent 行为和约束写进 AGENTS.md（仓库中的代理行为约定），并用 TECHNICAL_DEBT.md（记录技术债与待办重构项）保持改动时的上下文与可审计性。有人主张将 LLM 的中间输出版本化（存入 git 以保留工作过程），并维持运行闭环让 agent 定期评估自身效果并反馈改进；一位评论者分享了用 Claude 运行循环并产生“improvement engine”的亲身经验。与此同时，也有评论质疑原文是否清晰地把这些主张连成可执行流程，认为论证不够连贯，实际操作细节缺失。
agent: 在讨论中指基于大型语言模型的自动化代理（software agent），负责串联工具、执行任务和决策；区分为通用（general-purpose）agent与针对特定领域的专用agent。
AGENTS.md: 一种仓库内文档约定，用于记录和约束代理的行为规范、权限与运行约定，以便在代码审查和版本控制中治理 agent 行为。
TECHNICAL_DEBT.md: 用于跟踪技术债务的清单式文档，记录需重构的设计、已知问题和后续改进项，帮助在 agent 自动改动场景中保留可处理的技术债上下文。
improvement engine: 一种模式或子系统，让 agent 或外部流程定期分析自身日志/会话与指标、识别模式并生成改进建议，再把这些建议反馈回 agent 的自我优化机制。
模型拒绝（refusal）: LLM 或 agent 在面对超出能力、触及安全边界或高复杂度请求时声明无法执行的行为；讨论重点在于区分合理的保护性拒绝与阻碍工作的错误拒绝（false refusals）。