IPO 法律工作往往不是缺少材料，而是材料太多、版本太密、关联关系太复杂。Cooley 构建的 GO Public 将 ChatGPT Work 引入 IPO 流程，目标并非替代律师作出法律判断，而是更早暴露潜在问题，让律师把时间集中在真正需要专业判断的地方。
这一案例值得关注的，不只是“律师开始使用 AI”，而是 AI 被嵌入了一条高风险、强审计、多人协作的专业流程。对其他团队而言，最可借鉴的思路是：先让模型承担问题发现和信息整理，再由专业人员完成证据核验与最终决策。
IPO 流程为什么适合“问题发现型”AI
IPO 项目涉及招股文件、公司治理材料、风险因素、财务披露、重大合同和多轮问答。传统检查往往依靠清单、搜索、人工交叉阅读和团队经验，容易遇到三个问题：
- 问题发现得太晚：某项披露缺口可能直到后期审阅才出现，随后牵动多个版本。
- 信息分散：同一事实可能出现在董事会材料、合同和招股文件的不同段落中。
- 专家时间被低价值比对占用：律师需要花大量时间定位差异，真正用于解释风险的时间反而减少。
大语言模型擅长从长文本中提取实体、归纳主题、比较表述并按照检查框架生成候选问题。因此，一个合理的定位不是“AI 判断披露是否合规”，而是让它回答更受控的问题：
- 哪些事项可能需要进一步披露？
- 同一事实在不同材料中的描述是否存在差异？
- 哪些结论缺少对应证据或原文位置？
- 哪些问题应该升级给证券律师、财务团队或公司管理层？
GO Public 所体现的价值就在这里：把智能能力放到流程前端，提前建立问题队列，而不是等最终文件形成后才做一次笼统检查。
真正有用的输出不是摘要，而是可核验的问题单
面向专业工作的 AI 输出应当便于复核。与其生成一段流畅但难以验证的总结，不如要求模型返回结构化记录：
- 问题类别；
- 风险级别；
- 原文摘录及位置；
- 为什么值得检查；
- 建议向谁提问；
- 当前置信度；
- 是否已经由人工确认。
例如，模型可以标记“重大客户集中度在两份材料中的比例不同”，但不能直接断言某一数字错误。律师需要回到原始材料，确认日期、统计口径和文件版本，再决定是否修改披露。
这种设计把模型从“答案生成器”变成“审查助手”。模型负责扩大检查覆盖面，人负责认定事实、解释规则并承担决策责任。
可以这样实践：生成一份可追踪的初审问题清单
下面是一个最小化示例，用模型分析一份虚构或已脱敏的项目材料，并输出 JSON 问题单。它不是 GO Public 的内部实现，只是根据该案例目标设计的参考工作流。
运行前请确认：
- 只使用组织批准的模型和数据处理环境；
- 不要把真实客户材料发送到未经批准的公共端点；
- 将
OPENAI_MODEL改成组织允许使用、且支持 JSON 输出的模型； - 安装 SDK，并设置 API 密钥。
python -m venv .venv
source .venv/bin/activate
pip install "openai>=1.0.0"
export OPENAI_API_KEY="replace-with-your-key"
export OPENAI_MODEL="your-approved-model"
mkdir -p documents
cat > documents/sample.txt <<'EOF'
Draft registration statement: Customer A represented approximately 18% of revenue in fiscal 2024.
Board presentation dated January 15: Customer A represented 24% of revenue for the latest twelve months.
The company experienced a service outage in November. The current risk-factor draft discusses general availability risks but does not mention the incident.
EOF
保存以下脚本为 review.py：
import json
import os
from pathlib import Path
from openai import OpenAI
SOURCE = Path("documents/sample.txt")
OUTPUT = Path("issues.json")
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
model = os.environ["OPENAI_MODEL"]
text = SOURCE.read_text(encoding="utf-8")
system_prompt = """
You are an issue-spotting assistant supporting an IPO legal review.
Do not give a final legal conclusion and do not invent facts.
Identify only matters supported by the supplied text.
Return a JSON object with an `issues` array. Each issue must contain:
- category
- severity: low, medium, or high
- evidence: an exact quotation from the source
- reason_for_review
- question_for_human
- confidence: a number from 0 to 1
If the text does not support an issue, omit it.
""".strip()
response = client.chat.completions.create(
model=model,
temperature=0,
response_format={"type": "json_object"},
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": f"Review this material:\n\n{text}"},
],
)
raw = response.choices[0].message.content
data = json.loads(raw)
for issue in data.get("issues", []):
issue["human_status"] = "unreviewed"
issue["source_file"] = str(SOURCE)
OUTPUT.write_text(
json.dumps(data, ensure_ascii=False, indent=2),
encoding="utf-8",
)
print(f"Wrote {len(data.get('issues', []))} issues to {OUTPUT}")
执行：
python review.py
cat issues.json
在真实系统中，还应把文件页码、段落编号、版本哈希和审阅人写入记录。没有准确来源定位的问题，不应直接进入正式法律意见或披露文件。
从演示走向生产，需要补上的控制层
单次提示词演示很容易，稳定的专业工作流则需要额外工程投入。
1. 权限与保密
IPO 材料通常高度敏感。系统需要继承原有文档权限，限制跨项目检索，并明确数据保留、模型训练和第三方处理政策。访问日志也应能够回答“谁在什么时间处理了哪一版文件”。
2. 版本与引用
一个正确但引用旧版本的答案仍然可能造成风险。每条问题记录都应绑定文件标识、版本、页码或段落，以及内容哈希。材料更新后，系统要能判断哪些问题需要重新运行或重新确认。
3. 人工复核
高风险问题不能自动关闭，也不能直接写回正式文件。建议设置清晰状态，例如：
unreviewed -> lawyer_confirmed -> owner_assigned -> resolved -> partner_approved
模型可以提出问题，但状态流转应由有权限的人完成。
4. 评测而非凭感觉验收
上线前可以使用历史案例构建脱敏测试集，重点测量：
- 已知重要问题的召回率；
- 无依据问题的比例；
- 引文与原文的一致率；
- 不同版本运行结果的稳定性；
- 律师确认一个问题所需的平均时间。
在法律场景中，“生成了很多问题”不等于效果好。过多误报会消耗律师注意力，最终让团队忽略真正重要的提示。
采用建议：从一个窄任务开始
GO Public 展示的是一种务实方向：让 AI 更早发现问题，而不是越过律师直接下结论。团队可以从单一、可衡量的任务切入，例如风险因素缺口检查、定义一致性检查，或不同版本之间的事实差异比较。
上线前至少确认以下事项：
- 数据环境是否经过安全和保密审批；
- 输出是否包含可回到原文的引用；
- 是否明确禁止模型作出最终法律结论；
- 高风险结果是否必须人工确认；
- 文件更新后是否会触发重新审查；
- 是否有脱敏评测集和持续质量指标；
- 团队能否追溯每次模型调用及后续修改。
AI 在这类流程中的最佳角色，不是替代专业判断，而是帮助专业人员更早看到不一致、遗漏和待确认事项。只有把引用、权限、版本和人工责任一起设计进去，速度提升才不会以牺牲可靠性为代价。