团队用看板管理任务，最头疼的不是任务怎么拆，而是讨论怎么留痕。之前摸鱼看板里，一个任务卡片的上下文全靠标题和描述撑着，遇到"这个接口返回格式改了""前端需要同步调整"这类需要来回说的事，只能靠群聊截图补。v1.3.0 上线的任务评论系统，把讨论直接钉在了任务详情里——评论、回复、@提及、Markdown，一条龙解决。
评论系统的四个关键能力
评论与回复：讨论有层级，不是一锅粥
任务详情页底部新增评论区，团队成员可以直接对任务发表评论，也可以针对某条评论进行回复。回复挂在父评论下面，形成清晰的讨论线程，而不是所有消息平铺在一起。这意味着"接口字段变更"和"前端适配方案"可以分两条线索展开，不会互相淹没。
@提及：让该看到的人立刻看到
评论中输入 @ 会触发成员选择器，选中后该成员收到通知。这比在群里喊一句"某某你看下这个任务"靠谱得多——通知直接关联到具体任务上下文，点进去就能看到完整讨论链路，不用再翻聊天记录找上下文。
倒序展示：最新讨论永远在最上面
评论区按时间倒序排列，最新评论置顶。日常使用中，大家最关心的永远是最近的状态——"昨天说的那个问题今天修了没"，倒序展示省掉了滚到底部再往上翻的操作。
Markdown 支持：评论不只是纯文本
评论支持 Markdown 格式，这意味着你可以在讨论里贴代码片段、加粗关键结论、列步骤清单，甚至嵌入表格对比方案。对于技术团队来说，一条带代码块的评论比十条纯文字描述都管用。
写一条真正有用的 Markdown 评论
下面是一个在摸鱼看板任务评论中可以直接使用的 Markdown 示例，展示如何把讨论写得结构清晰、信息密度高：
@张三 接口返回格式已调整，变更点如下：
**变更内容：**
- `status` 字段从 `string` 改为 `int`，0=失败，1=成功
- 新增 `retry_count` 字段，类型 `int`
**示例响应：**
```json
{
"status": 1,
"retry_count": 0,
"data": { "id": 42, "name": "测试项目" }
}
前端需要同步修改 handleResponse 里的判断逻辑，从 res.status === "success" 改为 res.status === 1。
预计影响范围：订单列表页、详情页。我先改列表页，详情页 @李四 接一下。
这条评论同时完成了三件事：通知相关人、给出具体变更和代码示例、明确分工。比在群里发一句"接口改了你们看看"有效得多。
## 如果你要自建评论系统，数据结构可以这样设计
摸鱼看板的评论功能背后，核心数据模型并不复杂。如果你在自己的项目里要实现类似能力，可以参考以下结构：
```python
# comment 数据模型示例 - 可根据实际 ORM 调整
from datetime import datetime
from typing import Optional, List
class Comment:
"""任务评论模型，支持回复、@提及、Markdown 内容"""
id: str # 评论唯一 ID
task_id: str # 所属任务 ID
author_id: str # 评论者 ID
parent_id: Optional[str] # 回复目标评论 ID，None 表示顶级评论
content: str # Markdown 格式的评论正文
mentions: List[str] # 被 @提及的成员 ID 列表
created_at: datetime # 创建时间，用于倒序排序
def to_display_dict(self) -> dict:
"""渲染到前端时使用的结构"""
return {
"id": self.id,
"author": self.author_id,
"content_md": self.content, # 前端用 Markdown 渲染器展示
"mentions": self.mentions,
"created_at": self.created_at.isoformat(),
"replies": [], # 子评论查询后填充
}
# 创建评论的伪逻辑
def create_comment(task_id: str, author_id: str, content: str) -> Comment:
# 1. 从 content 中解析 @提及，提取成员 ID
mentions = extract_mentions(content) # 正则匹配 @username 模式
# 2. 存储评论
comment = Comment(
id=generate_id(),
task_id=task_id,
author_id=author_id,
parent_id=None,
content=content,
mentions=mentions,
created_at=datetime.utcnow(),
)
save(comment)
# 3. 给被提及的成员发通知
for member_id in mentions:
send_notification(member_id, comment)
return comment
def extract_mentions(text: str) -> List[str]:
"""从 Markdown 文本中提取 @提及的成员标识"""
import re
# 匹配 @用户名 的模式，用户名允许字母数字下划线
pattern = r"@([a-zA-Z0-9_]+)"
return re.findall(pattern, text)
几个实现要点值得注意：
- 倒序排序：查询时按
created_at DESC排序，前端直接渲染即可，无需额外反转。 - 回复层级：
parent_id为空的是顶级评论，有值的是回复。查询时先拿顶级评论，再按parent_id分组填充replies。 - @提及解析：存储时同时提取并保存
mentions列表，避免每次渲染都重新解析 Markdown。通知触发也放在创建环节，不延迟处理。 - Markdown 渲染：后端只存原文，前端用渲染器（如
markdown-it）实时渲染，这样编辑时看到的是源码，展示时看到的是格式化结果。
上手建议
升级到 v1.3.0 后，建议团队先做两件事：
- 把存量讨论迁移进来：之前散在群聊里的关键决策和变更说明，整理成评论贴到对应任务上。一条带 Markdown 的评论就能替代好几条零散的聊天消息，后续回溯也省力。
- 养成 @提及的习惯：评论里主动 @相关人，别默认"大家都会看到"。看板的通知机制比群聊更精准，@提及能让该负责的人第一时间收到信号，减少"我以为你知道了"这类误会。
评论系统解决的不是"能不能说话"的问题，而是"说的话能不能被找到、被关联、被追溯"的问题。讨论留在任务里，任务才有完整的上下文。