哈哈，今天咱就说个技术话题，不过别想着我要讲一堆枯燥的理论。说真的，Zuo过工单系统的人dou知道，那玩意儿真Neng把人逼疯。从拉单到排查再到结论评论，每一步dou可Neng掉坑里。今天我就跟大家聊聊咱们小鹅通内部用的super-xiaoe工单系统是怎么玩转自动化排查和闭环评论这回事儿。

啊，你得明白一个道理：没有标准化输入哪来标准化输出？咱们system里定义了几个固定触发词： - 排查工单{编号} - 排查{编号} 这个设计背后啊，其实藏着我们被烦透了的经历。早期用户随便打个字就让AI去排查？太容易跑偏了！必须严格限制输入格式才Neng保证后续流程可控。

那为什么不用Open API呢？不对不对不对...让我纠正下。实际上Web APIgeng稳定可用！早期试过DescribeIssue接口，结果总返回UnauthorizedOperation错误码。后来换成Web API就没问题了。这教训告诉我们：API选型不Neng图方便啊！

接下来就是知识库校验这个关键步骤。你可Neng会问："为什么要Zuo这个多余的检查？" 害...因为我们吃过太多亏了！ 每次有新人提交PR时总是忘记geng新业务入口文档knowledge-catalog.md。 所以现在Agent启动时必须先校验这个文件存在不存在。 "不存在就报错"这条硬性规则省了多少麻烦啊！

哦对了有人会问："为什么百度不收录我的网站？" - 可Neng是内容质量不过关 - 可Neng缺少有价值的原创内容 - 可NengSEO基础没Zuo好 - 或者百度蜘蛛抓取不到... 算了不说这些偏题的话了...

现在进入核心部分啦！Skill会根据问题类型进行智Neng分流： 1. 产品疑问走A路径 2. Bug排查走B路径 3. 数据推理走C路径

别以为所有问题dou要技术和客服双视角分析！这种思维太老土了。 "先判定类型再加载references" - 把资源精准投放到需要去处！ - token控制得geng好！ - 噪音减少hen多！

import json, os, urllib.request, re, sys CODING_TOKEN = os.environ.get ISSUE_CODE = sys.argv url = f'https://xiaoe.coding.net/api/project/.../issues/defects/{ISSUE_CODE}' req = urllib.request.Request(url, headers={ 'Authorization': f'token {CODING_TOKEN}', 'Content-Type': 'application/json', }) with urllib.request.urlopen as resp: issue = json.loads.decode) # 提取标题、优先级、状态、负责人等关键信息...

"产品解释模板"、"Bug根因归类模板"、"数据推理模板"...这些dou是经过无数次迭代优化出来的标准输出格式。 "结构化字段 + 截图分析 + CTT扫描去重" - 一眼就Nengkan懂重点！ - 去除冗余信息！ - 防止重复劳动！ db-proxy前置约束 - 安全第一

"每次SQL前必须读业务模块数据库表检索.json确认表存在情况..." "比如推广员表t_distributor按app_id末两位分表" - 查t_distributor_94而非全扫描 - 避免无谓的资源浪费 - 防止误操作 超重要! 不发送原则 & 用户确认机制!

这点绝对值得强调一下! "排查结束后不自动发送!" Skill会固定询问： " /super-xiaoe 排查工单63387 Yi完成 是否将结论评论到工单 #63387? 回复「评论」发送，「跳过」不评论，「修改:xxx」调整后再评" 为什么这样设计？ 因为我们曾经被AI误判结论烦透了! 手动确认这一步避免hen多尴尬场面! 落地执行 & 技术细节展

好啦开始讲技术细节!先上目录结构：

team-knowledge/
├── knowledge-catalog.md          # 业务域入口
├── biz-wiki/{domain}/            # 实体/踩坑/catalog
├── team-conventions/
│   └── *.json                    # 各种规范文件
└── .claude/skills/super-xiaoe/
    ├── SKILL.md                  # 主路由
    └── references/               # 各种参考文件
        ├── coding-ticket-fetch.md      # 拉单API+脚本模板
        ├── coding-comment.md           # 评论API+格式+反模式
        ...
注意事项：
1. 必须使用Python脚本避免中文JSON转义问题!
   
payload = json.dumps({
       'ProjectName': 'xianwangjishugongdan',
       'IssueCode': ISSUE_CODE,
   }, ensure_ascii=False)


python
POST https://e.coding.net/open-api/CreateIssueComment?Action=CreateIssueComment

GET https://xiaoe.coding.net/api/project//issues/defects/{IssueCode}
Authorization: token {CODING_TOKEN}

...等等!还有一个特别重要但容易被忽略的点:
本步结论 - 没有app_id和时间窗时直接暂停或反向追踪!
千万不要空转全库扫描!否则服务器会爆炸!
...对了还有:
"推理失败比错误结论geng安全!"
Skill明确要求用"推理失败"模板替代瞎编!
并且"不产生沉淀提议",避免污染知识库!
日志自愈 & 工具链演进思考篇
听我说!这条链路从「排查工单63387」到结论,
全程可在Cursor里用一条Skill跑完!
是否评论到Coding由研发决定回复「评»!
geng绝的是Bug路径在输出前强制根因归类:
代码缺陷 | 产品逻辑 | 数据异常 | 需求缺失...
并且要求≥方证据才Neng标「Yi证实」!
个人认为这是Zui难的一步:
如何平衡速度与准确性?
如何防止证据捆绑造假?
如何保持归类标准?
其实hen简单嘛...
通过团队协作建立共识!
逐渐形成默契!
Zui终变成文化基因!
Zui后给大家留个思考题:
Ru果把日志异常→建工单→深度根因三者结合,
是不是Ke以形成geng完美闭环?
这就是今天要分享的全部啦~希望对各位有所帮助!
记得点赞收藏哦~哈哈~