怎么回复评论：简短说清“收到”、提问和退回修改

发布日期：2026年10月30日

关于本连载

“团队任务管理技巧”是面向刚开始使用任务管理或项目管理工具的团队的连载，共 8 篇，另有 1 篇番外。不限行业，可以从任意一篇开始阅读。

番外篇“让语言不同的成员也能看懂的写法”（即将发布）

任务的评论区里，同一件事来来回回说了好几轮。对方迟迟不回复，连看没看过都不知道。这类情况，只要在写法上下点功夫，就能少很多。

注：本文由 GeckoFlag 的开发者撰写。

结论：第一行写结论，最后一行写请求

读的人看了第一行，就会判断“和自己有没有关系”。先写结论，最后写希望对方做的事。中间只放判断所需的内容。

不同场景的写法

表示收到时

只回一句“收到”，看不出收到的是什么，也不知道你什么时候做什么。要把下一步一起写上。

不好的例子	好的例子
收到。	收到。周四上午我会把第一版方案发上来。

不需要回复的消息，回一句“看到了”这样简短的反应就够了。如果工具有表情回应（用表情符号回应）的功能，就用它。

提问时

问题有好几个时，标上编号。对方也能按编号回答“第1点……”
尽量给出选项来问。比起“怎么办？”，问“选A还是B？”，回答的人负担更小
写明希望什么时候之前得到答复

退回（请对方修改）时

指明要改的位置：“第2页的标题”“右下角的电话号码”
附上理由：知道了理由，类似的地方对方也能自己改
把“必须改的”和“可以的话再改的”分开：所有内容写得一样重，对方会不知道该从哪里下手
开场白要短：怕语气太重而一层层铺垫，真正的请求反而会被淹没。想说做得好的地方，一句就够了

报告完成时

写清楚什么做完了、放在哪里、还有没有剩下的事。只写“做完了”，收到的人就得自己去找交付的东西。

可以直接套用的常用句

把 ___ 的部分换成实际内容即可。

收到

收到。我会在 ___ 日 ___ 点前完成 ___。

提问

关于 ___，想请教两个问题。

___ 是A还是B？
这次也需要 ___ 吗？

如果能在 ___ 日前回复，就可以按计划推进。

退回修改

已经看过了。麻烦修改以下两点。

（必须）把 ___ 的 ___ 改成 ___。理由：因为 ___。
（可以的话）把 ___ 再放大一些。

其他部分保持现状就可以。

完成报告

___ 已经完成。

存放位置：___
剩余事项：无（或 ___）

麻烦确认一下，谢谢。

延误通知

___ 赶不上 ___ 日的截止日期了。

原因：___

最晚 ___ 日可以交。也可以先把 ___ 发给您，您看哪种比较好？

写的时候要守的 3 条规则

1写明希望谁来读

在好几个人都能看到的评论区里，如果没写明对象，谁都不会觉得是在说自己。要写上对方的名字，或者选择要通知的人。

2写明需不需要回复

只要写上“无需回复”或“请在 ___ 日前回复”，等回复的时间就会减少。

3一个任务只谈一件事

聊起另一件事时，就新建一个任务。一个评论区里混进好几件事，事后就理不清定下了什么。

要说难以开口的事时

延误、失误、拒绝……越是难以开口的事，开场白越容易变长。按“发生了什么 → 有什么影响 → 打算怎么做”的顺序，简短地写出事实。道歉一句就够了，省下的篇幅用来把下一步写具体。

和聊天怎么分工

简单的商量，用聊天更快。不过，在聊天里定下的事，要在任务评论里用一句话留下来。因为聊天记录会被冲走，事后很难再找到（在入门连载的“邮件和聊天里托付的事为什么会被冲走？”中有详细说明）。

比如，曾经有这样的事

请对方修改时，用一句话写成“整体再亮一点，字也大一点，还有照片也……”，结果看不出哪些是必须的，来回了3次。后来改为标上编号、分开“必须”和“可以的话”，一次就改好的情况多了起来。

在 GeckoFlag 中可以这样沟通

评论可以用富文本撰写，也能使用编号列表。发表前可以预览。
发表评论的同时，可以修改状态、优先级和负责人。比如写完成报告时，可以把状态改为“待确认”，并把负责人改回提出请求的人。
每次发表时，都可以选择要通知的成员。“希望谁来读”每次都能自己决定。
可以用 20 种图标对评论进行表情回应，减少只写“看到了”的回复。
界面上显示最新的 3 条评论，更早的会折叠起来。长时间讨论后定下的事，最好也写进事项的描述里，读起来更清楚。

实际界面可以在演示中试用。

总结

评论要在第一行写结论，最后一行写请求。只要再写明希望谁来读、需不需要回复，来回沟通就会减少。下一篇将介绍用来传达进度的“状态”怎么定。

连载也欢迎阅读第4篇“怎么定负责人和截止日期”

连载下一篇：第6篇“进度怎么传达？”