试了试 cc 新推出的 /insight 功能，总结的蛮有道理。其中 建议添加到 CLAUDE .md 这个功能非常有用，建议大家自己跑一次看看。 --- 关键模式: 你作为高速度独立创始人运作,发出快速的多任务指令,期望 Claude 自主执行,仅在采取错误方法时进行敏锐纠正。 你是一位极其高产、以运营为重的开发者,将 Claude Code 作为快速执行伙伴,处理复杂全栈产品。在短短 6 天内就有 39 个会话、504 条消息和 92 次提交(平均每天约 8 小时),你保持着无情的交付节奏。你的工作流程明显是多任务和中断驱动的 — 会话通常将 3-5 个不相关任务(bug 修复、部署、UI 调整、基础设施变更、计费集成)捆绑到单个对话中,当生产问题浮现或优先级变化时,你经常在会话中途转向。你不写详细的前期规范;相反,你发出简洁的指令,期望 Claude 搞清楚实现细节,在出错时介入纠正。例如,当 Claude 误解了你的演示示例功能(以为你想要实时执行而不是提供预先存在的文件),或者编辑了错误的 Dockerfile 时,你快速纠正并继续前进。 你的互动风格显示出对迭代的高容忍度,但对错误方法的低容忍度。你让 Claude 在直接任务上自主运行(Bash 是你最常用的工具,使用了 958 次,反映了对 Claude 在部署、服务器管理和调查方面的重度依赖),但当 Claude 调查错误根本原因或做出错误假设时,你会敏锐地介入 — 如 Claude 反复追查视频渲染 bug 的错误原因而不是听你清楚解释,或者它试图启动 localhost 服务器而不是检查你已经运行的应用程序时。摩擦数据讲述了一个清晰的故事:"错误方法"(34 个实例)和"buggy 代码"(29 个实例)是你最大的痛点,它们源于你推动的变更的巨大数量和速度。你本质上是在和 Claude 作为工程团队一起运行单人冲刺,级联 bug(如导致卷数据丢失的沙箱路由修复,或覆盖 codeben 的错误项目部署)是这种速度的代价。 尽管存在摩擦,你始终将会话评为有帮助并持续使用 — 128 个"可能满意"的评分主导你的满意度概况。你的主要领域是涉及沙箱、AI 代理、Stripe 计费和视频处理的 TypeScript 密集型 SaaS 产品,你最依赖 Claude 进行 bug 修复(28 个目标)和多文件更改(18 次成功)。你很少要求解释或规划 — 只有 6 个"信息查询"目标和 2 个"良好解释"成功 — 强化了你将 Claude 用作实际执行者而非顾问的事实。当事情出错时,你的本能是推进另一个修复,而不是退后重新架构。