跳到正文
沉默土豆.
搜索标签中文/EN
  • 开始
  • 写作
  • 专栏
  • 项目
  • 研究
  • 咨询
  • 影像
  • 关于

写作

文档不是记录,而是协作接口

一份技术文档的实用写法:先把结论和问题写清楚,再用合适的结构承接方案、进度与细节。

LiyukLiyuk发布于 2020年10月22日更新于 2026年8月14日约 6 分钟阅读
  • #写作
  • #Technical Writing
  • #沟通
  • #工作与领导力
  1. 1文档不是记录,而是协作接口短文 · 约 6 分钟阅读本篇
  2. 2技术知识库为什么需要入口页短文 · 约 6 分钟阅读
  3. 3把口语想法写成可决策的文档短文 · 约 5 分钟阅读

如果这篇文章对你有帮助,请我喝杯咖啡吧——你的支持让我有动力继续写下去。

微信
支付宝

感谢支持,量力而行。

分享到

X微博TelegramWhatsAppLinkedInFacebook

微信

用微信扫一扫

在手机上打开这篇文章,或转发给朋友。

喜欢这个站?

或订阅 RSS
← 上一篇成就感不是奖励:关于压力、交付与自我认可
下一篇 →一次可复用的工程复盘,应该留下什么
查看专栏《文档与知识》目录下一篇:技术知识库为什么需要入口页 →

继续阅读

也许和这篇有关。

  • 写作把口语想法写成可决策的文档把散乱想法蒸馏成一篇能讨论、能落地的文档:工具负责整理,人负责判断。阅读全文 →

    同专栏 · 共享标签 3 个

  • 写作主题式一对一:从"不知道聊什么"到一份话题地图一次对话解决一个问题,每个主题 30 到 60 分钟。这套系列的使用方法、话题总览与收尾三原则。阅读全文 →

    共享标签 2 个

  • 写作从定义问题开始:一次一对一怎么开场不知道怎么开场、不知道聊什么,就从"把问题定义清楚"开始。给上下级都能照着一问一答的问题清单。阅读全文 →

    共享标签 2 个

© 2018–2026 Liyuk。缓慢构建,公开发布。

在别处GitHub ↗X ↗LinkedIn ↗邮箱 ↗友链 ↗收藏 ↗订阅 RSS ↗
CC BY-NC-SA 4.0