施工日志（正文版 · 抬头表格 + 九大项正文）
把「现场口述」变成一份可直接打印签字归档的 Word。结构固定、字段固定，每日一份。
与「施工日记全流程」的分工：本技能负责单日日志的快速成稿；需要花名册校验、Web 人工复核、批量导出月度归档时，改用「施工日记全流程」技能，不要在本技能里重复造。
一、输出结构（固定，不得增删栏目）
施 工 日 志
┌ 固定抬头（表格）──────────────┐
│ 工程名称（整行，拉到最右侧） │
│ 建设单位 │ ... │ 监理单位 │ ... │ ← 四单位首次登记后自动回填
│ 施工单位 │ ... │ 日期 │ ... │
│ 温度 │ ... │ 气候 │ ... │ ← 手填，不联网
└──────────────────────────────┘
一、每日班前教育会 教育内容 / 参加人数（只写总人数）+ 主持人
二、施工部位 施工部位：……
三、施工内容 1）楼栋工作面 工序 人员机械 完成进度 ← 纯内容，不带标签、不写待补充尾巴
（项目负责人、记录人不在此处单列，只在落款签字处体现）
四、隐蔽工程验收 1）验收部位 验收内容 结论 ← 监理旁站、允许下道工序不进正文；未注明问题即记「合格」
五、设计变更 1）变更内容 收到时间 ← 只记这两项，交底一律不写在这
六、技术交底 1）交底部位 交底内容 交底人 接受交底班组 交底日期 ← 变更引发的交底记这里
七、质安闭环 7.1 质量检查 1）问题 整改人 完成时间
7.2 安全记录 1）问题 整改人 完成时间
八、材料进场验收数量、取样送检 1）材料名称 规格 进场数量 已取样送检 ← 送检措辞不带标签
九、材料领用情况 1）材料名称 规格 领用数量 领用班组 领用人
十、其他事项 1）事项类型 内容 影响 交底/确认 ← 商务洽商 / 暂停施工 / 窝工
记录人___ 项目负责人___ 日期___
- 只有抬头是表格，第三项起全部为正文段落：
标签：值用制表位对齐，多条记录按1）2）3）编号成行，字段间用全角空格分隔。 - 第三项「施工内容」写纯内容，不带任何标签：
1）6号楼 5层 钢筋绑扎 钢筋工 20人；塔吊 1台 绑扎 12.5t，累计完成 80%。禁止写成「楼栋 / 工作面：… 施工内容：… 人员机械：… 完成进度：…」。其余各项（四、五、六、七、八、九、十）仍保留标签：值形式。 - 「待补充」不留在第三项里：某个字段没数据就整段省略，不写「待补充（当日绑扎量待现场核定）」这种尾巴。没有人数就只写「8号楼 10层 外脚手架搭设」，宁短勿假。
- 原第八项「机械、设备安装、拆除及维护」已取消，不再单列栏目；塔吊、施工升降机等只在用户明确提到时才写进第三项对应工作面（如「钢筋工 20人；塔吊 1台配合吊装」）。
⚠ 不得自行补机械：用户没提塔吊、泵车、吊篮，就别写（哪怕现场"显然"要用塔吊）。没有输入就没有记录。 - 十项全部渲染，无内容时显式写「无 / 待补充」（第三项除外——它按上条规则省略字段，不留尾巴）。
- 施工内容按楼栋工作面分段，末段写「完成进度」（当日量 + 累计百分比），不是笼统完成量合计。
- 抬头表格锁定固定列宽（标签列 2.8cm、值列 5.9cm，左右各 8.7cm），合并单元格按 gridSpan 累加宽度，工程名称整行项与监理单位、日期右边界齐平。
- 质安两栏只有三个字段：问题、整改人、完成时间。不得加「检查结论」「复查人」。
- 隐蔽验收是硬闸门：结论非「合格 / 整改后合格」时
next_allowed必须为「否」；填「是」会被脚本红字拦截并告警。 supervisor（监理旁站）与next_allowed（允许下道工序）仍需写进 spec，但不再渲染进正文——仅用于脚本红线校验（未通过禁止下道 / 越权放行告警）。正文一行只留「部位 内容 结论」。- 验收默认口径：当日记到隐蔽验收、且用户没说有问题的，一律按合格记录（脚本对空
result自动补「合格」）。只有用户明确指出返工/不合格时才记「整改后合格 / 待整改」，此时next_allowed必须为「否」。 - 设计变更为第五大项（排在隐蔽验收之后），字段
design_change[]：只有content变更内容 +received收到变更时间两项。变更部位、单号并入 content 文字里；不写影响、不写交底——变更引发的技术交底一律记在第六项技术交底。脚本对旧的part/impact/disclosure做兼容忽略。 - 无照片功能：脚本不再嵌入任何图片，spec 里的
photos/work_photos/hidden_photos一律忽略。
二、标准流程
步骤 0 · 工程登记（仅首次，一个工程一次）
用户第一次给某工程的日志时，先确认四单位，一次登记后永久复用：
python scripts/init_project.py --name "工程名称" --owner "建设单位" \
--supervisor "监理单位" --contractor "施工单位" --root "<台账根目录>"
产出 <台账根目录>/<工程名称>/project_config.json。此后每日生成都带 --project-config，四单位自动回填，不再重复问。
监理单位填「无」即无监理项目。已有配置时脚本不覆盖（覆盖加 --force）。
步骤 1 · 采集当日信息
用户习惯给简洁数字串（如「2号楼3层 顶板模板 木工12人 塔吊1台 320平 累计60%」）。
按 references/填写规范.md 的措辞库规整成标准字段。缺失的必填项才追问，一次问完：
日期、温度、气候、施工部位、施工内容（含楼栋/工作面）、项目负责人、记录人。其余缺项写「待补充」，不阻断出稿。
采集时按以下口径归并，不要在成稿里展开：班前会人数只汇总总人数；塔吊等机械写进对应工作面的「人员机械」，不单列设备栏。
步骤 2 · 写 spec.json
结构见 assets/spec.example.json：
{
"date": "2026-10-03", "temperature": "26℃", "climate": "晴",
"briefing": {"content": "...", "attendees": "28人", "host": "安全员 陈××"},
"location": "2号楼 3层（3-1~3-12 轴）",
"work": [{"area": "2号楼 3层", "content": "顶板模板安装",
"crew": "木工 12人；塔吊 1台", "progress": "320㎡，累计完成 60%"}],
"manager": "张××", "recorder": "李××",
"hidden": [{"area": "2号楼 3层 顶板", "content": "钢筋绑扎", "result": "合格",
"supervisor": "监理 刘××旁站", "next_allowed": "是"}],
"tech_disclosure": [{"part": "2号楼 3层 顶板", "content": "顶板模板安装专项交底：起拱 1/1000、立杆间距 ≤900mm",
"by": "技术负责人 王××", "to": "木工班组（孙××）", "date": "2026-10-03"}],
"quality": [{"issue": "...", "fixer": "王××", "due": "2026-10-04 17:00"}],
"safety": [{"issue": "...", "fixer": "陈××", "due": "2026-10-03 下班前"}],
"materials_in": [{"name": "", "spec": "", "qty": "", "sample": "已取样送检"}],
"materials_out": [{"name": "", "spec": "", "qty": "", "team": "", "person": ""}],
"design_change": [{"content": "", "received": ""}],
"others": [{"type": "商务洽商", "content": "", "impact": "", "disclosure": ""}],
"other": ""
}
> spec 书写口径（已定版，勿回退）
> - briefing.attendees 只写汇总总人数「61人」，不列工种明细。
> - work[].crew 里只写用户明确提到的人与机械（用户提了塔吊才写「钢筋工 20人；塔吊 1台」），不得想当然补「塔吊配合吊装」。
> - work[] 里没数据的字段直接留空串 ""，脚本会省略该段；不要写「待补充（当日……待现场核定）」。
> - 隐蔽验收未注明问题 → result 写「合格」（空值脚本也会自动补）。
> - 设计变更写进 design_change[]（content + received），只记内容与收到时间，不写进 others[]。
步骤 3 · 生成 Word
python scripts/build_log.py --spec spec.json \
--project-config "<台账根目录>/<工程名>/project_config.json" \
--out "<台账根目录>/<工程名>/施工日志_2026-10-03.docx"
- 输出路径约定：
<台账根目录>/<工程名称>/施工日志_YYYY-MM-DD.docx（根目录由用户指定，脚本内无任何硬编码路径） - 依赖
python-docx（仅此一个三方依赖；标准库 argparse/json/os/sys/re 即可运行）。安装：pip install python-docx - 脚本末尾会打印
WARN N 条，列出验收未通过放行、材料不合格等问题
步骤 4 · 回执
生成后必须：① 用 present_files 打开 docx 供用户直接查看；② 文字回执给出文件路径 + 当日要点摘要（部位/主要完成进度 + 未闭环的质安问题及整改责任人 + 隐蔽验收结论 + 技术交底项）。
脚本输出的 WARN 必须在回执中逐条转述，尤其是验收未通过放行。
三、补记与多天
- 补记往日日志：改
date即可，文件名随之变化，不与当日日志冲突。 - 一次记多天：每个日期各写一份 spec、各生成一份 docx，不得把多天塞进一份。
四、红线（每次出稿前自查）
- 不编造：天气、人数、工程量、责任人、验收结论、交底内容、养护时间，缺则写「待补充」。天气手填，本技能不联网。
- 不代判：不写「质量合格」「安全无隐患」这类结论，只记事实与整改安排。
- 不合并：不同工作面、不同工序、不同问题、不同交底各占一行。
- 不留空：任何栏无内容必须显式写「无」或「待补充」，禁止空白。
- 不越权放行：隐蔽验收未通过不得标「允许下道工序」，脚本红字拦截，人工不得绕过。
- 不事后补记交底：技术交底必须在实际作业前完成，交底日期不得晚于该项施工日期。
- 不加表格：除固定抬头外，任何项都不得用表格呈现，只能写正文段落。
五、资源
scripts/init_project.py— 工程登记，产出 project_config.json（四单位）scripts/build_log.py— spec.json → Word（抬头表格 + 正文十项，含出稿自检告警）assets/spec.example.json— spec 结构示例references/填写规范.md— 十大项字段规则、工序措辞库、质安与交底写法、红线清单
