最近比较心仪的一篇文章：
大概的主旨是，对于编程来说，代码只是执行，AI 将逐步接管「如何做」的执行问题，人类工程师的核心竞争力将转移到定义「做什么」（What）和「为什么做」（Why）上，而竞争力的核心在于包含代码所需全部信息的「结构化沟通」本身。
但「结构化沟通」这个词语有些抽象，不如简化为「结构化表达」，是指把杂乱、模糊的想法，按照一定的逻辑、层次和标准，整理成清晰、易于理解和执行的内容。
这样的转变，让我重新思考一个曾经被滥用的说法：人人都是产品经理。
因为长久以来，产品经理的工作本身就是把模糊的需求，按照一定的逻辑、层次用自然语言整理成清晰、易于被理解的内容。结构化表达的文档能力一定程度上就约等于一个产品经理的工作能力。
以前我也很鄙夷「人人都是产品经理」的说法，含混不清，拉低门槛、语境滥用，但 AI 无孔不入的现在，我反而觉得这句话有些正面意义。像产品经理一样去拆解想法并结构化表达，最终让其他人或 AI 能方便理解和执行我们的想法，一举多得。
而当我们像产品经理那样尝试结构化表达，我们可以：
1. 面向目标的内容组织
像产品经理那样写文档，从问题或目标来组织内容，而不是简单的信息堆砌。让每一部分都回答一个问题：这部分内容到底是为了解决什么？
2. 有逻辑的层次安排
当我们把复杂的想法拆分为多个模块，需要按先后、主次、有依赖关系的方式排列，这样可以让 AI 或者协作的同事能快速抓住重点、看清上下文关系，更容易参与讨论与给出反馈。
3. 有可行性的表达
表达肯定不只是描述问题或想法，而是明确地说清楚：预期要达成什么结果，要做什么、不做什么，边界在哪里，期望输出是什么。并且，即使暂时想不清楚，也可以将预期效果说给 AI 听一听，与 AI 一起将模糊的地方逐步清晰化。
4. 基于文档的协作推进
像产品经理那样通过文档来推动协作，这也意味着，结构化表达的内容本身要能够保留原始意图，也能随着讨论、反馈不断迭代更新。
换句话说，文档本身是「活的」，它不是一次性完成的产出物。我们在文档中留下的，不只是当前的决策和计划，也包括上下文、演变过程和背后的思考逻辑，让 AI 能像真的 Copilot（副驾驶）那样了解所有上下文。
不过，如果觉得要考虑的点太多，其实，所有的结构化表达可以简化为一个基本意识，那就是 「文档或者表达首先是写给别人看的，其次是自己」，这样就可以了。
站在「别人」的角度不一定能立马成功，但至少是一个有意识的开始。