先说结论
Odoo 项目里的快速建任务，并不是“标题输入框比较聪明”这么简单。
在 /home/ubuntu/odoo-temp/addons/project/models/project_task.py 里，官方把 display_name 的帮助文案直接写成了一套语法说明：
#tags：给任务加标签@user：给任务分配负责人! / !! / !!!：设置优先级
这说明它不是模糊猜测，而是带约定的轻语法输入。
所以你看到下面这些现象时，不要惊讶：
- 打了
@某人却没分配成功 - 写了
#feature结果没有加标签 - 连打感叹号，优先级却不对
- 同一个标题在不同数据库里解析结果不一样
问题通常不在“输入框抽风”，而在语法命中、数据存在性、命名规范、以及团队是否把这个特性当正式流程来用。
第一层：为什么官方要做这种“半自然语言输入”
项目系统里最怕的不是字段多，而是录入阻力高。
如果每建一个任务都要：
- 点新建
- 填标题
- 点标签
- 选负责人
- 设优先级
- 再保存
在高频分派场景里，效率会很差。
所以 Odoo 提供了一种折中方案：
- 界面仍是普通任务创建
- 但标题支持内嵌控制片段
- 常用结构由解析器拆出去，落到真正字段上
本质上，这是一种把结构化录入压缩到一行文本里的设计。
它适合：
- 临时分派
- 周会快速记卡片
- 运营团队批量记待办
- 开发或实施团队快速建 issue / task
但它不适合“想怎么写就怎么写”。
第二层：这套语法解决的不是可读性，而是录入速度
很多人第一次看到 #tag @user !!!，会把它当作一种很酷的命名风格。
其实官方要解决的是效率，不是美观。
源码帮助文案甚至给了推荐顺序：
- 任务标题正文
#tag@user!
例如：
Improve the configuration screen #feature #v16 @Mitchell !
这不是装饰，而是告诉你：
任务名称和控制指令最好有清晰分隔，且遵循固定次序。
如果团队把这种语法写得七零八落，例如：
@Tom 修复打印格式 ##urgent开发!!! @小王 #bug #客户A#重要 @Alice 优化库存接口 ! !
那解析成功率就会下降，协作的人也很难预判最终结果。
第三层：为什么 @user 最容易出问题
快速创建里最常见的抱怨就是：
- 我明明写了
@user - 为什么负责人没带出来
这个问题本质上有三个原因。
1. 命中的其实是显示名/别名规则，不是“你心里想的是谁”
如果数据库里用户名、显示名、昵称不统一，解析器不一定能猜到你的意图。
2. 同名或近似名会让输入语法失去确定性
团队里有多个 “Tom” / “Tina” / “王伟” 时，单纯依赖文本语法本来就危险。
3. 被分配的人必须是可分配对象
user_ids 的 domain 明确限制为：
- 不是 share 用户
- 是 active 用户
也就是说，某些门户用户、停用用户，本来就不该被这条快捷语法命中。
所以排错顺序很简单：
- 先确认这个用户是否 active
- 再确认是不是内部用户而不是 share 用户
- 再确认团队命名是否足够唯一
- 最后才怀疑解析本身
第四层：为什么 #tag 也不是写了就一定有
#tag 的前提，是项目里真的有对应标签体系，或者允许在交互里即时命中已有标签。
如果团队没有统一标签命名：
bugBugBUG客户问题issue
同一件事可能被输入成五种写法。
那快速创建不会变成效率工具，反而会变成数据污染入口。
所以这类功能真正落地前，最好先做两件事：
- 先定标签字典
- 再教团队按字典输入
不要反过来。
第五层：感叹号优先级为什么容易被高估
很多团队看到 ! / !! / !!! 很兴奋，因为它录入很快。
但优先级从来不是“越快越好”，而是“越一致越好”。
快速语法的优点是：
- 能在记录时顺手带出轻量优先级
它的边界是：
- 无法替代团队自己的排期规则
- 无法表达复杂依赖
- 无法替代表单里的完整业务上下文
换句话说，!!! 只能说明“很急”，不能自动回答：
- 为什么急
- 谁批准急
- 是否会挤占别的任务
- 急到什么 SLA
所以别把这个输入技巧神化成调度系统。
第六层：什么时候该用，什么时候别用
适合用
- 周会现场快速记 action item
- 实施项目临时拆任务
- 个人待办快速入库
- 熟悉团队内部统一命名规范后，高频录入
不适合用
- 新员工尚未理解标签/负责人命名规则
- 大规模外部协同，参与者名字重复严重
- 任务需要严格字段校验
- 需要同步填写客户、截止日期、项目属性等复杂字段
一个实用建议：把“快速输入”当快捷入口，不要当唯一入口
真正成熟的做法不是要求所有人都用这种语法，而是：
- 高频场景允许熟练用户快录
- 正式整理时仍鼓励检查结构字段
- 关键流程继续靠标准表单约束
这样你既能保留效率，也不会把数据质量押在“大家都写得够规范”上。
最后一句
Odoo 快速建任务这类特性，表面看像是小彩蛋，实际上很典型地体现了 Odoo 的设计思路：
允许用户用更轻的方式进入系统，但最后仍要落到正式字段和正式语义上。
所以别把它理解成“输入框懂我”，而应理解成：
- 有明确语法
- 有明确边界
- 有明确失败条件
- 有明确适用场景
把这点想清楚，这个功能才会真的提高效率，而不是制造脏数据。
DISCUSSION
评论区