页面不能代表全部能力
一篇漂亮文章只能证明你能写出漂亮文字，却无法说明你如何发现缺失信息、选择受众、处理冲突要求或验证最终步骤。
每个作品最好都像一个小型 case study。
先解释问题
说明读者是谁、需要完成什么任务，以及当时有哪些约束：产品行为不完整、多版本、紧迫 release、受监管术语或复杂迁移。
然后展示你改了什么、为什么改。一个结构的 before/after 往往比最终截图更能说明能力。
展示不同类型的证据
一个样例可以是 procedure，另一个可以是 API reference，再一个可以是信息架构或质量自动化。如果商业内容不能公开，可以用开源产品重建类似问题，或在不泄露机密的前提下匿名化结构。
展示验证方式
说明你如何测试命令、验证示例、与 subject-matter expert 合作，以及如何确认改动解决了问题。没有证据的“业务影响”不要写。
让作品集容易 review
三个强 case study 通常比二十个孤立链接更有价值。每个提供短摘要，让 reviewer 能快速打开真正的 artifact，并确认链接和图片不需要额外权限。
作品集最终要回答：这个人能够为我们解决什么样的文档问题？
实践示例
把《技术写作者作品集应该展示决策，而不仅是页面》变成一个短小、结果可观察的练习。选择一到两次练习就能完成的成果：一页操作步骤、一个 API 示例、一次前后对照编辑、术语清理或一个小型作品集案例。开始前先定义“更好”具体意味着什么。
保留过程证据，而不只保留最终页面：
- 原始问题和受众；
- 做出的决定和放弃的方案；
- 读者、审阅者或专家的反馈；
- 下一次会改变的一件事。
这比被动积累课程更有效。技术写作是在约束下反复做决定的手艺；一个完成并经过真实审阅的小练习，通常比从未交给读者的大型理论项目更有价值。
快速编辑检查
- 页面不能代表全部能力. 一篇漂亮文章只能证明你能写出漂亮文字，却无法说明你如何发现缺失信息、选择受众、处理冲突要求或验证最终步骤。
- 先解释问题. 说明读者是谁、需要完成什么任务，以及当时有哪些约束：产品行为不完整、多版本、紧迫 release、受监管术语或复杂迁移。
- 展示不同类型的证据. 一个样例可以是 procedure，另一个可以是 API reference，再一个可以是信息架构或质量自动化。
- 展示验证方式. 说明你如何测试命令、验证示例、与 subject-matter expert 合作，以及如何确认改动解决了问题。
