采访工程师准备技术文章时，最值得追问的是“什么条件下成立、依据在哪里、什么时候不成立”，而不是反复要求对方概括产品优势。一次可用的资料访谈，应让编辑拿到明确的问题、可公开的材料、准确的限制和需要继续确认的空白。下面的工作表可以直接抄进内部文档，不需要把口头聊天包装成研究报告。
开访谈前，把题目缩小到一个读者动作
“介绍一下我们的技术实力”太大，容易得到宣传语言。换成“采购者确认接线方向前应准备什么资料”，工程师更容易指出具体文件。邀请时就说明文章的目标读者、计划回答的疑问、已查看材料和不准备涉及的范围，并请对方带来允许使用的图、手册或样件。
访谈借鉴的是开放、非诱导的问题设计。GOV.UK用户研究指南建议用开放且中立的问题鼓励受访者展开，并围绕真实事例而非笼统的“应该怎样”提问。[6] 这不是专门给工业文章制定的规范，以下把这一方法用于编辑资料访谈，不声称已经开展了真实客户研究。
原创访谈场景示意，非光算团队或客户照片。录音与拍摄应先说明用途并取得适当许可，样件及图纸也要确认可公开范围。
可以直接填写的资料工作表
一条技术结论用一组记录，不要把整场访谈压成一句“工程师已确认”。以下字段可以复制；空白代表待确认，不能由写手自行补成肯定答案。
- 读者问题：读者正准备做什么，卡在哪一步？
- 对象范围：产品系列、文件版本、适用场景是什么？哪些相近对象不包括在内？
- 当前说法：工程师的原意是什么？准确引语与编辑概括分开记。
- 成立条件：需要哪些输入、环境或配置？读者怎样取得这些信息？
- 依据材料：文件名、版本、章节或图号；只有口头经验时如实标注。
- 反例和限制：换了哪项条件，这句话就不再成立？
- 公开范围：哪些文字、图片、参数可以使用，哪些只能内部参考？
- 后续确认：谁补什么材料，何时复核，什么情况才算完成？
如果同一问题涉及设计、生产和售后，不要让一个人替所有部门作答。记录每个人实际确认的部分，再把冲突交回相关人员澄清。比如设计手册与售后经验不一致，不能选择更有利于宣传的那一句。
工作表中也可留一个“本次不能回答”的位置。它用于区分需要补文件、需要找另一位负责人，以及本来就不能公开的问题；这三种空白不能交给写手用常识统一填满。
把“性能更好”问成可以写的内容
以下对话是教学示例，并非采访记录。工程师说“新版维护更方便”，编辑可以问：“维护哪个部位时方便？旧版通常要先拆什么？新版改变了哪个步骤？这份说明适用于哪些安装方向？”如果对方提到时间变短，再问时间如何记录、是否同一操作条件，不能直接写一个改进百分比。
当对方说“通常都可以”时，追问“你最先排除哪一种情况”。反例往往能帮助编辑给出更准确的限制。如果工程师表示必须看安装图才能判断，就把“需要哪张图、图中看哪些位置”写成读者的下一步，不逼对方给无条件的答案。
“有没有报告证明？”也可能问得太早。先弄清这是设计原理、制造能力、经验判断还是测试结果，再找对应依据。结构图能解释部件关系，但不自动证明寿命；设备清单能说明拥有某台设备，但不能替代某产品的检测记录。
现场多看一个对象，少问一个大词
在获得许可的前提下，请工程师指着样件、图纸或手册解释。“这里具体是哪一个接口”“你说的间隙对应哪条尺寸线”，能减少文字转述中的误解。编辑可以拍下获准公开的局部，同时记清对象版本与拍摄用途。不要把整张工作台照片带出去，里面可能有其他客户的图纸或铭牌。
若问题最初来自销售邮件，访谈前先完成客户问题的脱敏与公开判断。工程师需要理解技术条件，不一定需要知道客户姓名、交易金额和全部邮件往来。
访谈结束后，先交还结论清单，再交长稿
整理成短句，让工程师核对：我们准备写什么、依据哪份材料、适用什么条件、哪些内容仍不能写。遗漏的限制在这一步补回来，比整篇文章排版好后再重写轻松。确认用语应具体，例如“已确认该图用于解释接口位置”，不要写成“工程师认证文章全部正确”。
Google的有用内容自评同时关注清楚的来源，以及作者或审核者是否真正了解主题。[1] 若企业计划署名或标明技术审核，应按实际参与情况记录，不虚构职称与履历。工程师只提供了样件名称，就不能被写成全文审核人。
需要外部团队组织资料与撰稿时，可以在光算的谷歌SEO服务中约定内容建设工作；访谈安排、技术审核、图片处理和语言版本数量按项目确定。访谈的目的不是为文章添一段公司实力介绍，通用宣传文字可以按照公司介绍与主题正文的分工另行处理。
一场访谈结束后，如果记录中仍只有“更可靠、更高效、更专业”，先不要安排写稿。把缺少的条件与材料列回工作表，下次只补这些具体空白。