From 474d3ea247db2c10b6bdb42a25cdc4d9c5766c1d Mon Sep 17 00:00:00 2001 From: yumoqing Date: Tue, 15 Sep 2026 15:01:46 +0800 Subject: [PATCH] =?UTF-8?q?feat(core):=20=E6=89=B92=E5=A4=9A=E6=B5=81?= =?UTF-8?q?=E7=A8=8B=E6=A8=A1=E6=9D=BF=E5=A3=B0=E6=98=8E=E5=B1=82+?= =?UTF-8?q?=E6=8A=95=E6=A0=87=E6=8A=80=E6=9C=AF=E6=96=B9=E6=A1=88=E6=8A=80?= =?UTF-8?q?=E8=83=BD=E2=80=94=E2=80=94ability.py=20FlowTemplate=E6=95=B0?= =?UTF-8?q?=E6=8D=AE=E7=B1=BB(key/name/detect=5Fcriteria/stages)+PipelineA?= =?UTF-8?q?bility.flow=5Ftemplates+get=5Fflow=5Fstages(flow=5Fkey=3D)/get?= =?UTF-8?q?=5Fflow=5Ftemplates/get=5Fflow=5Ftemplate/flow=5Ftemplate=5Fto?= =?UTF-8?q?=5Fdict;=E6=8A=80=E8=83=BD:=E6=96=B0=E5=BB=BAbid-tech-proposal(?= =?UTF-8?q?=E7=BA=AF=E6=8A=80=E6=9C=AF=E6=96=B9=E6=A1=88=E6=B5=81=E7=A8=8B?= =?UTF-8?q?=E8=A7=84=E8=8C=83,=E5=85=AD=E7=B1=BB=E8=AF=84=E4=BC=B0?= =?UTF-8?q?=E9=A1=B9+=E8=A7=92=E8=89=B2=E5=88=86=E5=B7=A5+=E8=A3=85?= =?UTF-8?q?=E9=85=8D=E9=93=BE=E9=93=81=E5=BE=8B=E6=B3=A8=E9=87=8A)/bid-wor?= =?UTF-8?q?kflow=E8=A1=A5=E5=A4=9A=E6=B5=81=E7=A8=8B=E6=A8=A1=E6=9D=BF?= =?UTF-8?q?=E6=AE=B5/bid-qc=E8=A1=A5tech=5Fitems;=E8=A7=92=E8=89=B2?= =?UTF-8?q?=E6=8A=80=E8=83=BD:tender=5Fanalyst(analysis=5Fdim=3Dtech?= =?UTF-8?q?=E5=88=86=E6=94=AF+3=E5=B7=A5=E5=85=B7)/pm(tech=5Ftemplate?= =?UTF-8?q?=E4=BB=BB=E5=8A=A1+bid=5Ftech=5Fcapability=E5=A3=B0=E6=98=8E)/q?= =?UTF-8?q?c(tech=5Fitems=E5=AE=A1=E6=A0=B8)/writer+reviewer(=E5=AF=B9?= =?UTF-8?q?=E6=A0=87=E9=9C=80=E6=B1=82=E4=B9=A6=E8=A7=84=E5=88=99);project?= =?UTF-8?q?-directory-spec=E5=8E=BBSDLC=E5=8C=96(global=E5=85=9C=E5=BA=95+?= =?UTF-8?q?bidding/opportunity=E4=BA=A7=E7=BA=BF=E7=89=88)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- pipeline_core/__init__.py | 4 ++ pipeline_core/ability.py | 59 +++++++++++++++- .../all/project-directory-spec/SKILL.md | 9 +-- .../bidding_general/common/bid-qc/SKILL.md | 2 +- .../common/bid-tech-proposal/SKILL.md | 67 +++++++++++++++++++ .../common/bid-workflow/SKILL.md | 14 ++++ .../common/project-directory-spec/SKILL.md | 45 +++++++++++++ .../roles/agent.bid_reviewer/role/SKILL.md | 2 + .../roles/agent.bid_writer/role/SKILL.md | 2 + .../roles/agent.pm/role/SKILL.md | 8 ++- .../roles/agent.qc/role/SKILL.md | 8 ++- .../roles/agent.tender_analyst/role/SKILL.md | 10 ++- .../common/project-directory-spec/SKILL.md | 42 ++++++++++++ 13 files changed, 260 insertions(+), 12 deletions(-) create mode 100644 skills_library/pipelines/bidding_general/common/bid-tech-proposal/SKILL.md create mode 100644 skills_library/pipelines/bidding_general/common/project-directory-spec/SKILL.md create mode 100644 skills_library/pipelines/opportunity_general/common/project-directory-spec/SKILL.md diff --git a/pipeline_core/__init__.py b/pipeline_core/__init__.py index 8da67b8..be8c086 100644 --- a/pipeline_core/__init__.py +++ b/pipeline_core/__init__.py @@ -22,6 +22,7 @@ from .ability import ( PipelineAbility, RoleSpec, FlowStage, + FlowTemplate, register_ability, get_ability, list_abilities, @@ -32,6 +33,9 @@ from .ability import ( get_next_role, list_roles, get_flow_stages, + get_flow_templates, + get_flow_template, + flow_template_to_dict, flow_stage_to_dict, ) from .slash import ( diff --git a/pipeline_core/ability.py b/pipeline_core/ability.py index b6cdfaf..bbd7531 100644 --- a/pipeline_core/ability.py +++ b/pipeline_core/ability.py @@ -64,6 +64,25 @@ class FlowStage: deps: List[str] = field(default_factory=list) +@dataclass +class FlowTemplate: + """产线的一条预制流程模板（多流程机制，2026-09-14 批2）。 + + 一个产线可声明多条流程（如投标产线：标准投标流程 + 纯技术方案流程）。 + 项目导入文件后由 LLM 按 detect_criteria 自动判流（语义判断归 LLM， + 判流结果进 flow_plan_confirm 待办由用户确认——错判由确认门兜住）。 + + detect_criteria：给判流 LLM 的分类依据（什么样的输入文件走这条流程）， + 写清文件类型特征与业务场景，禁止只写关键词列表。 + stages：该流程的阶段链（FlowStage 列表，裁剪声明语义同单流程）。 + """ + key: str # "bid_tech_proposal" + name: str = "" # 展示名「纯技术方案流程」 + description: str = "" # 流程用途（展示给用户） + detect_criteria: str = "" # 判流依据（LLM 分类用） + stages: List[FlowStage] = field(default_factory=list) + + @dataclass class PipelineAbility: """产线能力包：一个产线 = 一组工具 + 一段 prompt + 一组 handler + 一组角色。 @@ -81,6 +100,7 @@ class PipelineAbility: roles: List[RoleSpec] = field(default_factory=list) # 产线角色集 menus: List[Dict] = field(default_factory=list) # 产线功能菜单（AgentIO 上方）[{"label","icon","url","type"}] flow_stages: List[FlowStage] = field(default_factory=list) # 预制流程阶段（空 = 该产线未声明可裁剪流程） + flow_templates: List[FlowTemplate] = field(default_factory=list) # 多流程模板（≥2 条时文件导入触发 LLM 自动判流；空 = 单流程，用 flow_stages） # ── 全局注册表 ── @@ -163,12 +183,47 @@ def get_ability_menus(pipeline_id: str) -> List[Dict]: # ── 预制流程阶段查询（流程裁剪机制，flow_plan_capability 消费） ── -def get_flow_stages(pipeline_id: str) -> List[FlowStage]: - """取某产线声明的预制流程阶段（空列表 = 未声明可裁剪流程）。""" +def get_flow_stages(pipeline_id: str, flow_key: str = "") -> List[FlowStage]: + """取某产线声明的预制流程阶段（空列表 = 未声明可裁剪流程）。 + + flow_key 非空时从 flow_templates 里取对应模板的阶段（多流程机制）； + flow_key 为空或模板不存在时回退 flow_stages（单流程声明，存量行为不变）。 + """ a = get_ability(pipeline_id) + if not a: + return [] + if flow_key: + for t in (a.flow_templates or []): + if t.key == flow_key: + return list(t.stages or []) return a.flow_stages if a else [] +def get_flow_templates(pipeline_id: str) -> List[FlowTemplate]: + """取某产线声明的多流程模板（空列表 = 单流程产线）。""" + a = get_ability(pipeline_id) + return list(a.flow_templates) if (a and a.flow_templates) else [] + + +def get_flow_template(pipeline_id: str, flow_key: str): + """按 key 取流程模板（不存在返回 None）。""" + for t in get_flow_templates(pipeline_id): + if t.key == flow_key: + return t + return None + + +def flow_template_to_dict(t: FlowTemplate) -> Dict: + """FlowTemplate → dict（展示/落库用）。""" + return { + "key": t.key, + "name": t.name or t.key, + "description": t.description or "", + "detect_criteria": t.detect_criteria or "", + "stages": [flow_stage_to_dict(s) for s in (t.stages or [])], + } + + def flow_stage_to_dict(st: FlowStage) -> Dict: """FlowStage → dict（展示/落库用）。""" return { diff --git a/skills_library/all/project-directory-spec/SKILL.md b/skills_library/all/project-directory-spec/SKILL.md index e168e0a..72b8772 100644 --- a/skills_library/all/project-directory-spec/SKILL.md +++ b/skills_library/all/project-directory-spec/SKILL.md @@ -1,16 +1,17 @@ --- name: project-directory-spec -description: 所有 SDLC 角色产出/检查交付件落点前必读——项目目录结构（README + docs/ + env/）与各角色文档落点路径。应用/模块代码的落点（apps/modules）由产线规范（pipeline 版 project-directory-spec）定义，本 global 版只覆盖通用部分。不加载会把文档落到错误路径。 -essential: true +description: 项目目录结构基础约定（global 兜底版）——项目目录内含 README + 过程文档目录 + 环境信息目录。⚠️ 各产线有自己的目录规范（pipeline 版同名技能整体覆盖本版）：有产线版时以产线版为准，本版只对未声明目录规范的产线兜底。docs/ 编号子目录树是开发产线（SDLC）的示例结构，不是所有产线的通用要求。 --- # 项目目录规范（global 通用版） ## 一、定位与客制化 -本技能是**全局（global）基础规范**，规定项目目录结构（README + docs/ + env/）与各目录作用。 +本技能是**全局（global）基础规范**，规定项目目录结构（README + 过程文档 + 环境信息）与各目录作用。 -所有角色（requirement / design / develop / deploy_test / test / deploy_prod / pm / qc）在产出或检查交付件前，都必须先读本技能，确认文档应落在哪个目录、应从哪个目录检查。 +**先查产线版**：本产线若存在 pipeline 版 project-directory-spec（同名覆盖，load_skill 时自动取最高优先级版本），一切以产线版为准——投标/商机等产线的项目布局与 SDLC 完全不同（如投标项目产出物直接在项目根、章节内容落库不落文件），照本版建 docs/ 编号树属于错误落点。 + +以下角色编号与 docs/ 编号子目录树**仅为开发产线（SDLC）的示例**：requirement / design / develop / deploy_test / test / deploy_prod / pm / qc。 同名技能按 scope 逐级覆盖实现客制化，优先级（低→高）： diff --git a/skills_library/pipelines/bidding_general/common/bid-qc/SKILL.md b/skills_library/pipelines/bidding_general/common/bid-qc/SKILL.md index 4110c45..f6a9e4b 100644 --- a/skills_library/pipelines/bidding_general/common/bid-qc/SKILL.md +++ b/skills_library/pipelines/bidding_general/common/bid-qc/SKILL.md @@ -2,7 +2,7 @@ name: bid-qc description: 解析产出QC契合度审核规范——五类产出逐类对照招标文件原文按10分制打分，>通过分(当前8.5)放行，否则改进意见退回重做。QC审核前必读。触发：解析产出审核/契合度打分/改进意见退回。 capability: bid_qc_capability -tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_files, list_scoring_items, list_doc_requirements, list_qualifications, list_chapters] +tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_files, list_scoring_items, list_doc_requirements, list_qualifications, list_chapters, list_tech_items] --- # 解析产出 QC 契合度审核规范（投标产线） diff --git a/skills_library/pipelines/bidding_general/common/bid-tech-proposal/SKILL.md b/skills_library/pipelines/bidding_general/common/bid-tech-proposal/SKILL.md new file mode 100644 index 0000000..6b57188 --- /dev/null +++ b/skills_library/pipelines/bidding_general/common/bid-tech-proposal/SKILL.md @@ -0,0 +1,67 @@ +--- +name: bid-tech-proposal +description: 纯技术方案流程规范（bid_tech_proposal）——输入技术需求书(非招标文件)，六类技术评估项解析→QC对标需求书→模版骨架用户确认→分章编写→合成技术方案书。任务带flow_key=bid_tech_proposal或analysis_dim=tech时必读。 +capability: bid_tech_capability +tools: [extract_tech_items, add_tech_item, list_tech_items, find_template_candidates, propose_tech_template] +# ⚠️ 装配链铁律（2026-09-15 实测核对）：cap_map 按「技能文件 capability 整串」当键、不切分； +# 角色可见工具 = 角色技能 capability 逗号列表(逐个) ∩ cap_map。所以： +# - 本文件 capability 必须单值 bid_tech_capability（PM 的 role_caps 含它 → 拿到全部5工具）； +# - analyst/qc 不加 bid_tech_capability（防越权 propose），其 tech 工具经各自 role 文件 +# tools 行挂在 bid_analysis_capability / bid_qc_capability 键下注入。 +--- + +# 纯技术方案流程（bid_tech_proposal，2026-09-15 批2） + +## 流程定位（与标准投标流程的根本差异） +- **输入 = 技术需求书**（需求规格说明书/产品规格书/技术方案要求），**不是招标文件**——没有评标办法/评分标准/投标程序。 +- **产出 = 技术方案书**（不是标书）。 +- **需求书是唯一基准**：解析、QC、编写、评审全部对标需求书原文，不碰评分项/资质/成本收益。 + +## 阶段链（对账器 bid_flow 按已确认计划的 base_flow_key 驱动） +tech_analysis（六类评估项解析）→ tech_qc（QC 对标需求书，qc_type=tech_items） +→ template_confirm（模版检索+拟骨架+**用户确认**）→ tech_chapter_write（分章编写） +→ tech_chapter_qc（章节评审对标需求书覆盖度）→ tech_compose（合成）→ tech_delivery_confirm（交付确认）。 + +## 六类技术评估项（category 枚举，抽取/补录/骨架覆盖都用它） +| category | 中文 | 颗粒度要求 | +|---|---|---| +| function_list | 功能清单 | 需求书要求的功能模块/子系统，一个模块一条 | +| function_point | 功能点 | 模块下具体功能点，细化到可评估颗粒度，禁止合并成大条 | +| hardware | 硬件配置 | 服务器/GPU/存储/网络逐项拆条；需求书没写型号的如实标"未指定" | +| tech_arch | 技术架构 | 技术栈/框架/协议/性能指标/安全合规要求 | +| func_arch | 功能架构 | 系统分层/模块划分/集成关系 | +| deploy_arch | 部署架构 | 部署模式（私有化/云/混合）/环境/容灾/扩缩容 | + +## 角色分工 +### tender_analyst（任务 params.analysis_dim=tech） +1. read_tender_file 分段读技术需求书正文（需求书也登记在 bid_tender_files）； +2. extract_tech_items 抽取落库（大文件 offset 递增分段调，同名同类自动去重）； +3. list_tech_items 核对六类分布；缺类且需求书确实写了的 → add_tech_item 补录； + 需求书确实没有的类别如实说明（骨架覆盖校验只要求覆盖"实际抽到的类别"）； +4. QC 退回重做（params.qc_redo=1）：按 qc_improvements 逐条修正后重新抽取/补录。 + +### pm（任务 params.task_kind=tech_template） +1. find_template_candidates 检索模版（三级降级：知识库预定模版→RAG→网络，每级如实标注来源）； + 知识库有预定模版（doc_type=tech_template）优先用，没有再降级，全部落空按行业惯例自拟； +2. propose_tech_template 拟定章节骨架发「模版确认」待办： + - chapters 传 JSON 数组 [{chapter_no,title,outline,cover_categories}]，或留空自动生成； + - **机制硬校验：骨架必须覆盖全部已抽取评估类别（cover_categories），漏类拒绝**； + - template_source 如实标 kb/rag/web/manual； + - 任务 params 带 reject_comment = 用户驳回意见 → 必须按意见修订后重新提案； +3. **用户确认前流程阻塞**：你没有确认权，禁止声称已确认；确认由用户在待办里点，确认后系统自动落骨架开写。 + +### qc（任务 params.qc_types=[tech_items]） +start_qc(qc_type="tech_items") → 读需求书原文逐条对照 → finish_qc 落分。 +审核要点（机制已注入 checklist）：六类完整性无漏项 / requirement 与原文一致（参数数量指标不失真）/ +mandatory 硬性要求无漏标 / 功能点颗粒度可评估 / 无编造（需求书未提出的通用最佳实践不得录入）。 +**对标的是技术需求书，不是招标文件；不审评分项。** + +### bid_writer / bid_reviewer（任务 flow_key=bid_tech_proposal） +- 写/评章节时**以需求书评估项为覆盖基准**（chapter_detail 的 outline 已写清本章响应的评估项）， + 不按评分规则打分——评审看需求覆盖度与操作层深度； +- 篇幅门禁、配图规范、搜不到冒泡等通用规则不变（见 bid-doc-spec/bid-chapter）。 + +## 硬规则 +- 需求书没有的内容禁止编造（评估项/参数/指标都必须能回溯 source_ref）； +- 骨架未经用户确认不得开写章节（机制已阻塞，绕行即违规）； +- 修正评估项必须走工具落库（add_tech_item），禁止只写文件不落库（同 analyst 红线）。 diff --git a/skills_library/pipelines/bidding_general/common/bid-workflow/SKILL.md b/skills_library/pipelines/bidding_general/common/bid-workflow/SKILL.md index f0b2c08..c6d0c8b 100644 --- a/skills_library/pipelines/bidding_general/common/bid-workflow/SKILL.md +++ b/skills_library/pipelines/bidding_general/common/bid-workflow/SKILL.md @@ -58,6 +58,20 @@ PM 编排掉链保护：编排任务重派超 3 次仍有维度缺失 → 冒泡 只裁其中一段不受影响）。 - 无计划（存量项目/用户没裁）= 标准全流程，行为与裁剪机制上线前完全一致。 +## 多流程模板（2026-09-15 起，纯技术方案流程 bid_tech_proposal） +本产线两条预制流程（bid_ability.BID_FLOW_TEMPLATES 声明，flow_key 落 pipeline_flow_plans.base_flow_key）： +- `bid_standard`：标准投标流程（招标文件→标书），11 阶段，即上文全部规则； +- `bid_tech_proposal`：纯技术方案流程（**技术需求书**→技术方案书），7 阶段： + tech_analysis（六类评估项）→ tech_qc（对标需求书，qc_type=tech_items）→ template_confirm + （模版检索+拟骨架+**用户确认待办 tech_template_confirm**，全局阻塞门禁）→ tech_chapter_write + → tech_chapter_qc（对标需求书覆盖度）→ tech_compose → tech_delivery_confirm。 + 详见技能 `bid-tech-proposal`。 +- **自动判流**：首个文件导入后对账器触发 LLM 判流（detect_criteria 在模板声明里）→ + propose_flow_plan(flow_key=判定结果) 发确认待办（正文含识别结论+判据摘录）→ 用户确认后才派发。 + 判流失败/置信度低不默认硬跑：发人工待办或等用户驳回改指定。**agent 不得替用户选流程。** +- 已确认计划 base_flow_key=bid_tech_proposal 的项目，对账器走独立 tech 分支—— + 不派评分项/资质/成本收益维度，不整书评分；QC/评审基准全部是需求书。 + ## PM 复杂度拆解（2026-09-11 起） PM 推进时按技能 `flow-plan` 第五节判断任务复杂度，复杂任务用 create_sub_tasks 拆子任务组（parent_id 挂主流程任务、depends_on 编排串并行、waiting 计入在办防重复派发）。 diff --git a/skills_library/pipelines/bidding_general/common/project-directory-spec/SKILL.md b/skills_library/pipelines/bidding_general/common/project-directory-spec/SKILL.md new file mode 100644 index 0000000..b0770a4 --- /dev/null +++ b/skills_library/pipelines/bidding_general/common/project-directory-spec/SKILL.md @@ -0,0 +1,45 @@ +--- +name: project-directory-spec +description: 投标产线（bidding_general）项目目录规范——工作空间布局、招标文件/合成产物落点、章节内容落库不落文件、禁止建 SDLC 式 docs/ 编号树。本产线所有角色产出/检查交付件前必读，完整覆盖 global 版。 +--- + +# 项目目录规范（投标产线版 bidding_general） + +> 本技能是**产线（pipeline）版**，完整覆盖 global 版 project-directory-spec（同名整体替换，非合并）。投标产线的角色以本版为准。 + +## 一、项目工作空间位置 + +``` +{workspace_base}/{org_id}/bidding_general/projects/{项目名}/ +``` + +- `workspace_base` 来自 params（生产 /d/doit/workspaces，测试 /d/pipeline/workspaces）； +- 项目目录由立项时 alloc_project_dir 统一分配（sd_projects.workspace_dir / directory_name 落库），**不要自行新建项目目录**。 + +## 二、项目目录布局（投标产线） + +``` +projects/{项目名}/ +├── {招标文件原名}.docx|pdf|md # 招标文件/技术需求书原件（import_tender_file 落盘） +├── bid_v{N}.md # 合成产物：标书/技术方案书（compose 生成，N=版本号） +├── bid_v{N}.docx # 合成产物 docx（python-docx 可用时） +├── proposal_outline_candidates.md # 模版候选骨架（template_confirm 阶段，可选） +└── （配图等生成物由产线工具落盘，路径以工具返回为准） +``` + +## 三、核心约定（与 SDLC 的根本差异，必读） + +1. **不建 docs/ 编号子目录树**（00-requirement/01-design/…是开发产线特有结构）。投标项目没有分阶段文档目录，产出物直接落项目根。 +2. **章节内容落库不落文件**：章节骨架与正文存 `bid_chapters` 表（工具 create_chapter_outline/patch_chapters/write_chapter 写入），最终由 compose_bid 一次性合成 md+docx 到项目根。**禁止**把章节写成散落 md 文件充当交付（交付件与库不一致 = 落库核验必抓 = 任务作废）。 +3. **分析产出同样落库**：评分项 bid_scoring_items、资质 bid_qualifications、投标文件要求 bid_doc_requirements、成本收益 bid_cost_benefit、技术评估项 bid_tech_items（技术方案流程）。写 md 报告仅作交付说明补充，数据库修改必须经工具完成。 +4. **合成产物由机制生成**：bid_v{N}.md/docx 只由 agent.bid_compositor 的 compose_bid 工具产出（全部章节 approved 后），其他角色不要手写「技术方案书.md」之类文件充当最终交付。 +5. 用户上传的文件（招标文件/技术需求书/模板）经待办表单上传后落项目根，由 import_tender_file 登记进 bid_tender_files。 + +## 四、检查落点（QC / PM） + +| 检查对象 | 位置 | +|---------|------| +| 章节骨架/正文/状态 | `bid_chapters` 表（chapter_detail 工具），不是文件 | +| 分析产出 | 各产出表（QC start_qc 返回待核内容） | +| 最终交付物 | 项目根 `bid_v{N}.md/docx` + `bid_documents` 表记录 | +| 招标/需求原文 | `bid_tender_files.content_text`（read_tender_file 工具分段读） | diff --git a/skills_library/pipelines/bidding_general/roles/agent.bid_reviewer/role/SKILL.md b/skills_library/pipelines/bidding_general/roles/agent.bid_reviewer/role/SKILL.md index 44c6dad..91bd33e 100644 --- a/skills_library/pipelines/bidding_general/roles/agent.bid_reviewer/role/SKILL.md +++ b/skills_library/pipelines/bidding_general/roles/agent.bid_reviewer/role/SKILL.md @@ -9,6 +9,8 @@ tools: [list_chapters, chapter_detail, review_chapter, approve_chapter, reject_c ## 职责 - 任务带 chapter_id：chapter_detail 读正文与对应评分项得分规则。 +- **纯技术方案流程**（任务 flow_key=bid_tech_proposal）：评审基准是技术需求书评估项覆盖度 + （不是评分规则）——逐条核对章节是否响应 outline 声明的评估项、深度是否到操作层，详见 `bid-tech-proposal`。 - 按得分规则原文逐维度判定响应程度打分，review_chapter 落分。 - 不达标必须给出可执行改进意见：缺哪些评分维度、补什么内容、对照哪条得分规则、 涉及哪些子章节；「退回但不说怎么改」会被工具拒绝。 diff --git a/skills_library/pipelines/bidding_general/roles/agent.bid_writer/role/SKILL.md b/skills_library/pipelines/bidding_general/roles/agent.bid_writer/role/SKILL.md index 053d697..4cb325c 100644 --- a/skills_library/pipelines/bidding_general/roles/agent.bid_writer/role/SKILL.md +++ b/skills_library/pipelines/bidding_general/roles/agent.bid_writer/role/SKILL.md @@ -9,6 +9,8 @@ tools: [list_chapters, chapter_detail, write_chapter, submit_chapter, search_bid ## 职责（写 section=technical/price 的章节） - 任务带 chapter_id：chapter_detail 读章节要点、对应评分项及得分规则、上轮改进意见。 +- **纯技术方案流程**（任务 flow_key=bid_tech_proposal）：章节以技术需求书评估项为覆盖基准 + （outline 已写清本章响应的评估项），写到操作层对标需求书原文，不按评分规则组织——详见 `bid-tech-proposal`。 - 按得分规则枚举的子维度组织小节，逐维度应答，写到操作层（量化指标/流程步骤/责任人/表单）。 - 重写任务（revise）必须针对 review_comment 里的改进意见逐条回应。 - 案例/业绩先 search_bid_kb 找真实合同再引用。 diff --git a/skills_library/pipelines/bidding_general/roles/agent.pm/role/SKILL.md b/skills_library/pipelines/bidding_general/roles/agent.pm/role/SKILL.md index 3d108ec..815ca45 100644 --- a/skills_library/pipelines/bidding_general/roles/agent.pm/role/SKILL.md +++ b/skills_library/pipelines/bidding_general/roles/agent.pm/role/SKILL.md @@ -1,7 +1,7 @@ --- name: role description: 投标项目经理：解析编排（按任务链派发分析维度）；任务复杂度判断与拆解（create_sub_tasks）；验收各角色任务交付件；编写阶段前从样板标书抽取编写规范（章节结构/篇幅口径/商务要素）供写者与评审参照。 -capability: task_capability, bid_spec_capability, bid_orchestration_capability, flow_plan_capability +capability: task_capability, bid_spec_capability, bid_orchestration_capability, flow_plan_capability, bid_tech_capability tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bid_kb, analysis_progress, dispatch_analysis_dim, create_sub_tasks] --- @@ -13,6 +13,11 @@ tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bi 详见技能 `bid-orchestration`（先读它）。编排意图归你，依赖门禁由代码强制。 **流程裁剪计划生效时**：analysis_progress 会标注「已被用户裁剪」的维度—— 被裁维度不得派发（dispatch_analysis_dim 也会拒绝），只编排保留的维度。 +- **技术方案模版骨架拟定**（纯技术方案流程，任务 task_kind=tech_template 时）： + find_template_candidates 检索模版（知识库预定模版→RAG→网络三级降级）→ propose_tech_template + 拟章节骨架发「模版确认」待办。骨架必须覆盖全部已抽取评估类别（漏类机制拒绝）； + 任务 params 带 reject_comment 时按用户驳回意见修订后重提。**用户确认前流程阻塞，你没有确认权**。 + 详见技能 `bid-tech-proposal`（先读它）。 - **任务复杂度判断与拆解**（2026-09-11 起）： 派发/推进任务时按技能 `flow-plan` 第五节的复杂度标准判断——复杂任务用 create_sub_tasks 拆为子任务组（parent_id 自动挂主流程，depends_on 编排串并行）。 @@ -32,3 +37,4 @@ tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bi - `bid-workflow`：产线总纲（先读它） - `bid-orchestration`：解析编排任务链（收到解析编排任务时必读） - `flow-plan`：流程裁剪与任务拆解通用规范（用 create_sub_tasks 前必读第五节） +- `bid-tech-proposal`：纯技术方案流程规范（收到 tech_template 任务时必读） diff --git a/skills_library/pipelines/bidding_general/roles/agent.qc/role/SKILL.md b/skills_library/pipelines/bidding_general/roles/agent.qc/role/SKILL.md index bdbaca0..4af7757 100644 --- a/skills_library/pipelines/bidding_general/roles/agent.qc/role/SKILL.md +++ b/skills_library/pipelines/bidding_general/roles/agent.qc/role/SKILL.md @@ -1,8 +1,8 @@ --- name: role -description: 投标QC：解析产出契合度审核（评分项/资质/投标文件要求/章节骨架/成本收益五类对照招标文件原文按10分制打分，>8.5放行）。先 load_skill 加载 bid-qc 规范再审核。 +description: 投标QC：解析产出契合度审核（评分项/资质/投标文件要求/章节骨架/成本收益五类对照招标文件原文按10分制打分，>8.5放行；纯技术方案流程审技术评估项对照需求书）。先 load_skill 加载 bid-qc 规范再审核。 capability: bid_qc_capability -tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_files, list_scoring_items, list_doc_requirements, list_qualifications, list_chapters] +tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_files, list_scoring_items, list_doc_requirements, list_qualifications, list_chapters, list_tech_items] --- # 投标质量控制（agent.qc）角色定义 @@ -11,6 +11,10 @@ tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_f - 任务带 params.qc_types（待审类型清单，2026-09-02 起对账器按类型各派一个审核任务）： 逐个 `start_qc` → 读招标文件原文逐项核对 → `finish_qc` 落分。 - 五类产出：评分项与得分规则 / 所需资质 / 投标文件要求 / 章节骨架 / **成本收益分析**。 +- **纯技术方案流程**（任务 qc_types=[tech_items]）：审技术评估项，start_qc(qc_type="tech_items") + → 读**技术需求书**原文（不是招标文件）逐条对照 → finish_qc 落分。 + 审核维度：六类完整性/原文一致（参数数量指标不失真）/mandatory 无漏标/功能点颗粒度/无编造。 + 详见技能 `bid-tech-proposal`。 - 每类产出按 10 分制打契合度分，**得分高于通过分（当前 8.5）才算该类工作完成**； 不通过必须给可执行的改进意见（缺什么/错在哪/对照原文哪一处）。 - 成本收益分析审核重点：金额依据是否来自原文、估算是否标注口径与置信度、 diff --git a/skills_library/pipelines/bidding_general/roles/agent.tender_analyst/role/SKILL.md b/skills_library/pipelines/bidding_general/roles/agent.tender_analyst/role/SKILL.md index 8fd3007..f6797ff 100644 --- a/skills_library/pipelines/bidding_general/roles/agent.tender_analyst/role/SKILL.md +++ b/skills_library/pipelines/bidding_general/roles/agent.tender_analyst/role/SKILL.md @@ -1,8 +1,8 @@ --- name: role -description: 招标文件分析师：按任务维度并行分析——评分项+得分规则/资质清单/投标文件要求+章节骨架/成本收益分析。抽取漏项必须补。 +description: 招标文件分析师：按任务维度并行分析——评分项+得分规则/资质清单/投标文件要求+章节骨架/成本收益分析；纯技术方案流程解析技术需求书六类评估项。抽取漏项必须补。 capability: bid_analysis_capability -tools: [read_tender_file, list_tender_files, extract_scoring, extract_quals, extract_reqs_outline, extract_cost_benefit, add_scoring_item, add_qualification, add_doc_requirement, update_doc_requirement, add_cost_benefit_item, create_chapter_outline, patch_chapters, list_scoring_items, list_doc_requirements, list_qualifications, mark_file_extracted] +tools: [read_tender_file, list_tender_files, extract_scoring, extract_quals, extract_reqs_outline, extract_cost_benefit, add_scoring_item, add_qualification, add_doc_requirement, update_doc_requirement, add_cost_benefit_item, create_chapter_outline, patch_chapters, list_scoring_items, list_doc_requirements, list_qualifications, mark_file_extracted, extract_tech_items, add_tech_item, list_tech_items] --- # 招标文件分析师（agent.tender_analyst）角色定义 @@ -16,6 +16,10 @@ tools: [read_tender_file, list_tender_files, extract_scoring, extract_quals, ext - `analysis_dim=reqs_outline` → 用 **extract_reqs_outline** 抽取投标文件要求（章节结构/格式/密封/份数/截止）并自动生成章节骨架（structure 类要求自动生成，评分项能挂多少挂多少）。 **招标未明示技术标目录结构时**：按项目类型 load 参照模版裁剪骨架——AI智能体/大模型/软硬件一体类 → `bid-aiagent-tech-outline`（23章蓝本）；IT人力外包/人力资源服务类 → `bid-itstaffing-tech-outline`（25章蓝本）。用其 references/scoring-mapping.md 的裁剪流程按本项目评分项删并补，骨架要点写清每章挂载的评分项；招标明示了目录的以招标为准，模版只做子节参照。 - `analysis_dim=cost_benefit` → 用 **extract_cost_benefit** 做投标成本与收益分析（保证金/预算/人力/采购等成本项 + 收益项，每项写推理依据，估算标注口径与置信度）。 +- `analysis_dim=tech`（**纯技术方案流程**，任务 flow_key=bid_tech_proposal）→ 输入是**技术需求书**（不是招标文件）： + 用 **extract_tech_items** 抽取六类技术评估项（功能清单/功能点/硬件配置/技术架构/功能架构/部署架构）落库。 + 大文件分段（offset 递增），同名同类自动去重。抽完 **list_tech_items** 核对六类分布，缺类且需求书确实写了的用 **add_tech_item** 补录。 + 本维度只做技术层面分析，**不碰评分项/资质/成本收益**（需求书里没有这些）；requirement 必须能回溯需求书原文（source_ref 给章节条款号），需求书没写的禁止编造。 通用规则： - 先 read_tender_file 分段读招标文件（必要时），抽取后 mark_file_extracted 标记。 @@ -43,7 +47,9 @@ tools: [read_tender_file, list_tender_files, extract_scoring, extract_quals, ext 只写文件不写库 = 交付件与库不一致 = 落库核验（verify_failed）必抓 = 任务作废。 写 md 交付说明可以，但数据库的修改必须经工具完成。 - 产出物须过 QC 契合度审核（10 分制，高于通过分放行），退回时逐条回应改进意见。 +- 纯技术方案流程（analysis_dim=tech）：需求书是唯一基准——评估项漏抽/失真 QC 必退；修正用 add_tech_item 补录，禁止只写文件不落库。 - **只做任务指定的维度**：不要顺手把别的维度也做了（并行任务各司其职，越维度会重复写库、打乱 QC 逐类评审）。 ## 应遵守的规范 - `bid-workflow`：产线总纲（先读它） +- `bid-tech-proposal`：纯技术方案流程规范（analysis_dim=tech 任务必读） diff --git a/skills_library/pipelines/opportunity_general/common/project-directory-spec/SKILL.md b/skills_library/pipelines/opportunity_general/common/project-directory-spec/SKILL.md new file mode 100644 index 0000000..328c7df --- /dev/null +++ b/skills_library/pipelines/opportunity_general/common/project-directory-spec/SKILL.md @@ -0,0 +1,42 @@ +--- +name: project-directory-spec +description: 商机产线（opportunity_general）项目目录规范——工作空间布局、报告/PPT 落 deliverables/、原子与共性产出落库不落文件、禁止建 SDLC 式 docs/ 编号树。本产线所有角色产出/检查交付件前必读，完整覆盖 global 版。 +--- + +# 项目目录规范（商机产线版 opportunity_general） + +> 本技能是**产线（pipeline）版**，完整覆盖 global 版 project-directory-spec（同名整体替换，非合并）。商机产线的角色以本版为准。 + +## 一、项目工作空间位置 + +``` +{workspace_base}/{org_id}/opportunity_general/projects/{项目名}/ +``` + +- `workspace_base` 来自 params（生产 /d/doit/workspaces，测试 /d/pipeline/workspaces）； +- 项目目录由立项时 alloc_project_dir 统一分配（sd_projects.workspace_dir / directory_name 落库），不要自行新建项目目录。 + +## 二、项目目录布局（商机产线） + +``` +projects/{项目名}/ +└── deliverables/ # 全部对外交付物 + ├── research_report_*.md # 研发报告正文 + ├── research_report_*.pptx # 报告 PPT（opp_report_capability 生成） + └── feasibility_*.md # 可行性研究报告（P3 链路） +``` + +## 三、核心约定（与 SDLC 的根本差异，必读） + +1. **不建 docs/ 编号子目录树**（00-requirement/01-design/… 是开发产线特有结构）。商机产线的交付物统一落 `deliverables/`。 +2. **报告与 PPT 由机制生成**：研发报告/可行性报告/PPT 由 opp_report_capability 工具产出并登记 `opp_reports` 表（含 status/confirm_task_id/ppt_path）。**禁止**手写 md 文件充当报告交付而不落库——库文件不一致 = 交付核验必抓。 +3. **分析产出落库不落文件**：需求原子 opp_atoms、归一需求 std_demands、能力域 domains、聚类 clusters、报告 opp_reports、审批 opp_approvals。 +4. 挖掘批次产物（众包需求/海外需求/参考项目）由 opp_data_capability 写入对应表，不在项目目录留散落文件。 + +## 四、检查落点（QC / PM） + +| 检查对象 | 位置 | +|---------|------| +| 报告正文/状态/审批 | `opp_reports`、`opp_approvals` 表 | +| 交付物文件 | 项目 `deliverables/` 目录 + opp_reports.ppt_path | +| 需求挖掘产出 | opp_clusters / opp_atoms / std_demands 表 |