6.0
关注
AI SCORE
开源项目2026-06-25 20:58
思维工程师工具包正式上线
DEV Community · Julien Avezou#开源工具#工作流
Editor brief · 编辑速览
开发者在 DEV 社区推出的 Thinking Engineer Toolkit 发布，汇集工程师工作流和思维方法论工具，获得社区热烈反响。
开发者在 DEV 社区推出的 Thinking Engineer Toolkit 发布，汇集工程师工作流和思维方法论工具，获得社区热烈反响。
过去几周，我一直在分享一系列围绕同一个问题展开的文章：
我们如何使用 AI，而不把自己的判断力也外包出去？
这个社区对这一系列文章的反响确实非常热烈。
这表明，与使用 AI 相关的认知卸载问题是真实存在的。在开发者群体中，这个问题引发了强烈共鸣。
一路上收到的评论、反馈和讨论，帮助我进一步打磨了这些想法，而它们如今已经发展成为 Thinking Engineer Toolkit。
能够在这里与你们分享这个系列、向其他工程师和 Builder 学习，并探索 AI 辅助工作正在如何改变我们思考、构建和理解软件的方式，是一段非常美好且富有启发的旅程。
感谢大家的意见和建议。
也感谢那些主动联系我、向我表达支持、鼓励与善意的人，我由衷地感谢你们。
期待未来能与大家展开更多讨论。
我原本想在这里直接标记参与度最高的社区成员，但每篇文章最多只能添加 10 个标签——这个限制很合理！因为我不希望任何人觉得自己被遗漏了，所以最终还是决定不这样做，毕竟我想标记的人绝对远不止 10 位！
这个 Toolkit 受到了我此前在 DEV 上分享的一系列文章的启发，欢迎查看：
《AI 时代的思考》——不要让 AI 替你思考：面向工程师的实用指南
《AI 时代的思考》——不要让 AI 替你思考：面向工程师的实用指南
《AI 时代的思考——团队版》——不要让 AI 破坏团队的集体思考：面向工程团队的实用指南
《AI 时代的思考——团队版》——不要让 AI 破坏团队的集体思考：面向工程团队的实用指南
《AI 时代的思考——Builder 版》——从 vibe coding 到清晰思考：AI 时代的非技术 Builder 需要什么
《AI 时代的思考——Builder 版》——从 vibe coding 到清晰思考：AI 时代的非技术 Builder 需要什么
《AI Thinking Balance Tracker》——使用 AI 的开发者所呈现的 4 种认知原型
《AI Thinking Balance Tracker》——使用 AI 的开发者所呈现的 4 种认知原型
《Prompt System Guide》——prompt engineering 中缺失的一层：思考质量
《Prompt System Guide》——prompt engineering 中缺失的一层：思考质量
《System Comprehension Heatmap》——你的代码库存在技术债，但你的团队是否也背负着理解债？
《System Comprehension Heatmap》——你的代码库存在技术债，但你的团队是否也背负着理解债？
每篇文章都探讨了同一个更大问题中的不同部分：
AI 正在让我们变得更快，但如果理解跟不上，速度本身并不足够。
我创办 The Thinking Engineer，是因为我不断在自己的工作流中察觉到一种张力。
AI 帮助我更快地推进工作。
它可以帮我进行头脑风暴、debug、重构、写作和构建。
但我也注意到，如果只是被动地使用 AI，它可能会让我的理解变得更加浅薄。
有时，我借助 AI 思考得更好了。
另一些时候，我却让 AI 替我思考得太多。
我把提高生产力与消除摩擦混为一谈了。
这种区别至关重要。
因为工程并不只是产出代码。
它还关乎判断、权衡、debug、沟通、理解系统，以及辨别某些看似正确、实际上却十分肤浅的东西。
这正是我想继续探索的问题：
我们如何在借助 AI 高效构建的同时，保留那些让工程工作具有价值的思考能力？
这个 Toolkit 汇集了 6 项资源：
面向个人工程师的指南，帮助他们使用 AI，同时避免削弱自身的推理能力、学习能力和技术直觉。
面向工程团队的指南，帮助团队在采用 AI 辅助工作流的同时，保留共同理解。
面向 Builder、创始人和非技术创作者的指南，帮助他们使用 AI 构建软件，同时不忽视自己正在创造的系统。
一份电子表格，帮助开发者观察自己如何在不同认知模式下使用 AI，包括学习、生成、debug、反思和执行。
一份电子表格，帮助团队识别对系统的理解在哪些地方很扎实、很脆弱，或危险地集中在少数人身上。
一份实用指南，帮助你使用 prompt，不仅获得更好的 AI 输出，也提升自己的思考质量。
每项资源都可以单独使用。
但组合在一起，它们就构成了一套完整的系统。
这些指南帮助你反思。
这些 Tracker 帮助你观察规律。
Heatmap 帮助团队发现理解债。
Prompt Guide 帮助你提升与 AI 交互的质量。
结合起来，它们构成了一套实用工作流，帮助你追问：
我是否在有意识地使用 AI？
我是否理解自己正在构建什么？
我的团队是否保留了共同理解？
我们是否正以一种能够持续积累学习成果的方式加速？
还是说，我们的加速方式只是在掩盖脆弱性？
根据我的亲身经历，这正是我从一开始就希望拥有的 Toolkit：一种围绕真正重要的问题，培养更好习惯的方法。
我认为，软件工程的下一个阶段，得到回报的不只是那些会使用 AI 工具的人。
那些既能使用 AI 工具，又能保留判断力的人，也将获得回报。
真正脱颖而出的工程师和 Builder，将是那些能够提出更好的问题、认真验证输出、深入理解系统，并且持续学习而不只是不断委派任务的人。
这就是我所说的 Thinking Engineer。
我从 DEV 社区感受到的一件事是：大家的普遍共识并不只是简单判断 AI 究竟是好还是坏。
我们该如何正确地使用 AI？
它会在哪些地方造成依赖？
这正是我想继续探讨的话题。
我们所扮演的角色正在发生变化。
这既令人兴奋，又让人害怕。
我们所有人都在同一时间摸索答案。
今天，我想免费与你分享 The Thinking Engineer Toolkit，帮助工程师和 Builder 在 AI 的辅助下高效且可持续地工作。如果你觉得它有价值，我也非常感谢你的任何支持，这样我就能继续投入时间，创作这类资源。
你可以在这里获取这个 Toolkit。
我很想知道，你在自己的工作流中是如何应对这些问题的：
你如何避免过度依赖 AI？
你是否制定了规则，决定什么时候使用 AI，什么时候先自己思考？
你是否已经看到团队或代码库中开始出现理解债？
怎样才能让这个 Toolkit 在实践中更加有用？
接下来我应该改进什么？
如需采取进一步行动，你可以考虑屏蔽此人和/或举报滥用行为。