AI Workflow & Enablement Portfolio

01 | 项目概述 Project Summary

一个轻量级 AI 工作流原型,用来把混乱的项目输入(甲方反馈、会议纪要、碎片化需求)转化为结构化、可追踪、可复用的输出——服务于项目推进与汇报沟通。

A lightweight AI workflow prototype that converts messy project inputs — client feedback, meeting notes, fragmented requests — into structured, traceable outputs for project execution and leadership communication.

一个以 workflow 为核心的项目系统：一个主原型，加上若干基于不同输入场景的验证分支，共用同一套输出 schema 与治理规则。它要解决的核心问题是：结构怎么设计、不确定性怎么显性管理、方法怎么沉淀成可复用、可教学的资产。

A workflow-oriented project system: one core prototype plus several validation branches grounded in different input scenarios, all sharing one output schema and one governance ruleset. The core problem it addresses is how the structure is designed, how uncertainty is made explicit, and how the method becomes a reusable, teachable asset.

02 | 为什么做这个 Why I Built This

在设计与项目场景里,关键信息经常分散在聊天、反馈和零碎记录中。这会带来五个反复出现的问题:

In design and project environments, important information is often scattered across conversations, feedback, and informal notes — creating five recurring problems:

• 任务遗漏 —— Key tasks easily missed
• 风险暴露滞后 —— Risks surface too late
• 未知信息被掩盖 —— Unknowns hidden instead of made explicit
• 输出不一致难复用 —— Outputs inconsistent and hard to reuse
• 汇报内容反复重写 —— Leadership communication rebuilt from scratch every time

这些不是"使用 AI 工具就能解决"的问题,而是需要设计一套结构化的工作流,才能让 AI 的输出真正落到执行层和汇报层。

These are not problems that "using an AI tool" can fix. They require designing a structured workflow to make AI output actually land at the execution and communication layers.

03 | 工作流怎么设计 Workflow Design

整套 workflow 围绕一个固定输出 schema展开,每个模块承担明确的功能:

The entire workflow is built around a fixed output schema, with each section serving a specific purpose:

输出结构 A–E / Output Structure A–E

• A. Executive Summary —— 30 秒可读完的汇报摘要,服务领导决策
• B. Task Table —— 可追踪任务表,含 Owner / Due / Priority / Dependency / Source Quote
• C. Risks & Mitigations —— 前置暴露的风险与对策
• D. Open Questions —— 显性化的未确认问题
• E. Assumptions & Source —— 假设与原句引用,用于追溯与边界控制

每个模块的设计目的:Executive Summary 让领导快速读懂、Task Table 落到执行、Risks 提前暴露、Open Questions 显性管理未知、Assumptions & Source 通过原句引用降低幻觉风险。

Each module serves a specific role: Executive Summary for fast leadership readability, Task Table for execution tracking, Risks for early surfacing, Open Questions for explicit unknown management, Assumptions & Source for traceability and hallucination reduction.

治理原则 / Governance Principles

为了让 AI 输出可靠、可追溯、可审阅,这套 workflow 定了几条硬规则:

To make AI output reliable, traceable, and reviewable, the workflow enforces several hard rules:

• 不编造缺失信息 —— No fabrication of missing facts, dates, owners, or decisions
• 未知信息显性化 —— Unknowns go into Open Questions / Assumptions, never hidden in Notes
• 原句溯源 —— Important interpretations link back to source quotes
• 字段规范 —— Due field is date-only or blank; Priority uses only P0–P3; no relative time
• 已知与未知分离 —— Known execution data and unresolved questions stay separate
• 对外使用前必须人工审核 —— Human review required before any external-facing communication

字段规范细则 / Field Discipline

• Priority —— 仅使用 P0 / P1 / P2 / P3
• Due —— 仅使用具体日期或留空,不使用"下周""明天"等相对时间
• Owner —— 负责人或 TBD,不留空
• Notes —— 仅放执行备注,不作为未知信息的兜底
• 任务用动作动词 —— "Define three direction strategies"(优), "Think about options"(劣)
• 输出语言明确控制 —— 标题双语 / 主体中文 / 数据库字段名英文

04 | 场景验证 Scenarios

这套 workflow 在 4 个真实场景下做了验证。每个 case 都包含真实的 messy input + 完整的 A-E 结构化输出,呈现同一套 workflow 如何承接不同类型的混乱输入。

The workflow was validated across 4 real scenarios. Each case captures real messy input + the full A-E structured output, showing how the same workflow handles different types of messy input.

4 个 case 共享的底层逻辑 / Unified Logic

虽然 4 个场景输入类型完全不同——客户变更 / 领导请求 / 内部会议 / 需求文档——但底层逻辑是一致的:

Although the 4 scenarios differ entirely in input type — client change / leadership request / internal meeting / requirement document — they share the same underlying logic:

• 把混乱输入转成结构化输出 —— Turn messy input into structured output
• 区分已知与未知 —— Separate knowns from unknowns
• 前置暴露风险 —— Surface risks early
• 支持后续行动 —— Support downstream action
• 提升可追踪性和复用性 —— Improve traceability and reuse

输入类型决定 schema 走向——对话型输入更易导向 actions,文档型输入更易导向 checklists 和 gaps。这就是为什么 schema 在不同场景下有差异化扩展,而不是强行用一张表打天下。

Input type drives schema direction — conversation inputs lean toward actions, document inputs lean toward checklists and gaps. That's why the schema has scenario-specific extensions rather than forcing one rigid table across all cases.

05 | 治理与边界 Governance & Boundary

边界和失败模式，和它能产出什么同样重要。

The boundaries and failure modes matter as much as what it produces.

它不是什么 / What It Is Not

• 不是决策替代品 —— 它帮助结构化思考、暴露任务和风险,但不替代设计判断、领导拍板、甲方确认
• 不是工程验证器 —— 可用于概念阶段规划与沟通,不能用来证明技术可行性、规范符合性、可施工性、造价确定性
• 不是 prompt 一次性输出 —— 是一套带有结构、治理、迭代、追溯的系统,不是"扔个 prompt 给 AI"

This workflow is not a decision-maker, not an engineering validator, and not a one-shot prompt. It is a system with structure, governance, iteration, and traceability.

5 种常见失败模式 / 5 Common Failure Modes

每一种失败都对应明确的修正方式——这些修正不是"再试试 prompt",而是在 prompt 和 review 中把规则写死:

Each failure mode has a defined fix — and the fix is not "try a different prompt," but encoding the rule into the prompt and review process:

• 语言混用 —— Mixed languages → 显式定义输出语言规则
• 字段漂移 —— Schema drift(优先级格式 / 相对时间)→ 锁定允许的 schema 值
• 任务太空 —— Tasks too abstract(主题而非行动)→ 要求 action-oriented 措辞
• 未知信息被编造 —— Unknowns fabricated(日期 / 责任人 / 决策)→ 要求 missing info 进 Open Questions / Assumptions
• 原句引用过度改写 —— Quotes too loose(被改写过度)→ 要求保留原始措辞

敏感数据最小化 / Sensitive Data Minimization

在使用 AI 处理项目资料前,敏感或保密信息应尽量减少或脱敏:身份信息、保密客户资料、内部预算细节、未公开决策内容。

Before using AI on project materials, sensitive or confidential information should be minimized or redacted: personal identifiers, confidential client information, internal budget details, non-public project decisions.

06 | 可教学可复用 Enablement

这套 workflow 从设计之初就考虑了可教学、可复用、可在相似场景中扩展。

The workflow was designed from the start to be teachable, reusable, and extensible across similar project scenarios.

谁适合用 / Who This Is For

经常处理碎片化项目信息的人:项目协调 / PMO / 运营、负责汇报的设计人员、处理甲方变更的团队成员、需要把混乱输入转成结构化行动的人。

Project coordinators, PMO / operations roles, designers preparing leadership updates, team members handling client changes — anyone translating messy inputs into structured actions.

5 步上手 / Quick Start

1. Prepare raw input —— 选一个 messy 输入源(甲方反馈 / 会议纪要 / 领导请求 / 内部聊天)
2. Use the standard prompt —— 把输入粘贴进固定 prompt 模板
3. Generate structured output —— 让 AI 输出 A-E 五大块
4. Review before reuse —— 检查信息完整性、结构合规性、原句引用、任务可执行性、语气适配性
5. Add tasks into shared database —— 把相关任务移入 Notion 任务数据库,含 Priority / Owner / Due / Dependency / Status / Project / Source Quote

一句话教学脚本 / One-line Teaching Script

我们不是让 AI 替代判断,而是让它先把混乱输入变成一个结构化初稿,帮助我们更快暴露任务、风险和缺失信息;真正用之前仍然要人工审核。

We use AI here not to replace judgment, but to turn messy inputs into a structured first draft. The workflow helps surface tasks, risks, and missing information faster. We still review everything before real communication.

当前已具备 / Currently in Place

固定输出 schema、可复用 prompt 结构、Notion 任务数据库、4 个场景验证案例、多轮 prompt 迭代记录。

Fixed output schema, reusable prompt structure, Notion task database, 4 scenario validations, multi-round prompt iteration records.

07 | 反思与下一步 Reflection & Next

当前状态 / Current Status

原型完成 + 初步验证。已完成结构设计、模板设计、Notion 数据库、4 个场景案例、两轮 prompt 迭代验证。第一轮暴露语言混用与字段漂移,第二轮通过加强 prompt 约束后,输出在语言一致性、结构稳定性、字段规范性上都有显著提升。

Prototype complete + early validation. Structure design, template definition, Notion database, 4 scenario cases, and two rounds of prompt iteration are all done. Round 1 exposed language inconsistency and schema drift; Round 2 significantly improved language consistency, schema compliance, and field discipline after tightening prompt rules.

已知 gap / Known Gaps

• 任务粒度仍可更 action-oriented
• 负责人分配规则仍偏保守(更多 TBD 而非具体角色)
• AI 输出与 Notion 数据库字段的对齐还不够完整
• 场景测试覆盖可继续扩展(更多输入类型、更多领域)

下一迭代方向 / Next Iteration

• 更清晰地定义"核心 schema + 扩展 schema"模型,让不同场景的字段差异有更明确的标准
• 进一步对齐 Notion 数据库,实现 AI 输出直接落库
• 加强任务与原句映射,提升 traceability
• 建立更明确的 review checklist,降低复用前的人工检查成本
• 视情况做多模型对比测试

一句话定位 / One-line Positioning

把散落在甲方反馈、会议纪要、碎片需求里的信息,收敛成结构化、可追踪、可复用的输出——同一套 schema 与治理规则,在四类不同的混乱输入下都成立。

It pulls information scattered across client feedback, meeting notes, and fragmented requests into structured, traceable, reusable output — one schema and one governance ruleset, holding across four different kinds of messy input.