软件开发边界控制五原则

最近在做一个项目，解析word成为在线试题，面对不断增加的需要解析的word格式，AI帮我总结出了如下原则来解决这个问题，我按照这个改造了一下代码，非常清晰，这里把这个原则分享一下

边界控制五原则（Word Parsing Scope Control 5 Rules）

🔒 Rule 1. 明确支持边界（Define What Is Supported）

只支持“结构合理+常见用法”的文档格式，其余记录但不立即支持

• 在项目说明文档中列出：目前支持的题型结构、样式规范、段落格式等。

• 明确声明：“项目不保证支持非规范或过于特殊的 Word 编排”。

📝 示例：

✅ 已支持格式：- 标题段以“1. 2. 3.” 或 “1、2、3、”开头- 答案以“答案：”字样开头- 选项段为 A. / B. / C. / D. 格式，支持带图片
⛔️ 不支持：- 题干和答案混排在一个段落的- 使用表格布局的选择题结构

🧪 Rule 2. 非预期格式记录，不立即支持（Log Instead of Patch）

所有未匹配的新格式，只记录日志并入库，不直接兼容。

• 设计一个**“异常格式收集机制”**（如 log 或 db 中一张 format_exception_log 表）

• 人工定期评估是否值得支持

• 强调：不是遇到就改，而是遇到就记。

🧱 Rule 3. 统一中间结构，所有格式转为标准中间态

将所有 Word 格式转为统一的“中间格式”（中间 JSON / XML / Markdown）

• 所有兼容逻辑只需要聚焦在“Word 到中间结构”的转换

• 后续逻辑只处理中间结构，避免跟 Word 格式耦合

📦 示例中间结构：

{
  "question_no": "3",
  "type": "single_choice",
  "content": "以下哪项不属于AI领域？",
  "options": {
    "A": "机器学习",
    "B": "深度学习",
    "C": "煎饼果子",
    "D": "自然语言处理"
  },
  "answer": "C",
  "image": null}

🧰 Rule 4. 所有兼容代码必须单独封装、可插拔（Modular Compatibility）

每种特殊格式，都用一个模块/类/策略对象处理，避免主流程变得复杂混乱。

📦 比如你可以这样设计：

class BaseParser:
    def match(self, doc): pass
    def parse(self, doc): pass

class DefaultFormatParser(BaseParser): ...
class TableStyleParser(BaseParser): ...
class TextImageMixedParser(BaseParser): ...

然后主程序只需：

for parser in all_parsers:
    if parser.match(doc):
        return parser.parse(doc)

🚨 Rule 5. 新格式支持必须通过“影响-收益”评估

引入支持之前，必须评估三个问题：

1. 是否高频？（用户是否经常上传这种格式）

2. 是否带来收益？（支持它会提高多少准确率、减少多少手工修改）

3. 是否可以泛化？（是否是通用场景，还是特例）

满足其中至少 2 项，才能安排开发兼容。

✅ 补充建议：

手机扫描二维码访问