7. 港口留下的東西
霧壓得很低,越過防波堤,碼頭盡頭的燈閃了兩下才亮起來。
瑪拉照著整間公司共用的系列聖經寫完初稿。她一送審,編輯的佇列就接到了。
第 7 章 · 審核中 · 2 小時前送審
出版社、編劇團隊、代筆工作室把影集聖經、風格規範、prompt 全部放在同一個地方——團隊裡每個寫手讀得到,坐在他旁邊的 AI 也讀得到。
霧壓得很低,越過防波堤,碼頭盡頭的燈閃了兩下才亮起來。
瑪拉照著整間公司共用的系列聖經寫完初稿。她一送審,編輯的佇列就接到了。
第 7 章 · 審核中 · 2 小時前送審
多數寫作團隊靠一個雲端資料夾、一個 wiki,加上每個寫手自己習慣的那個聊天助理在跑。撐得住,直到撐不住為止。
系列聖經、風格規範、你最好的那位編輯寫的 prompt。每個寫手的 AI 對話都從同一個來源取材,答案不再因為是誰問而不同。
擁有者、管理員、作者、審閱者。作者在團隊書裡寫;審閱者讀、留評論、核可,而且不佔席位。
寫手的 AI 照樣用得到那則 Skill。內文本身不會到他的機器上,而且每一次讀取都有紀錄。
聖經以檔案樹的形式存在,整個團隊都讀得到,還能語意檢索。AI 從你們的世界裡學到的東西會先進審核佇列——由管理者確認,才變成團隊的共同事實。
團隊方案目前沒有自助結帳,這是刻意的。封閉測試期間每一個團隊都由我們親手開通——席位、角色、知識庫——看它跑起來的樣子,再接下一個。
沒有閹割版的團隊方案。團隊裡的一個席位,拿到的是跟個人作者一樣的六種檔案、同一位教練、同一份版本歷史。
讀過每一章的教練——背後還有整份團隊知識庫。
每一次儲存都能還原。看得到誰改了什麼,兩份草稿都留著。
每一章都有狀態——草稿、審核中、已完成——編輯只要處理一條跨所有書的佇列。
PDF、EPUB、Word、Fountain。作品是你們的,想帶去哪都行。
每位作者通常半小時內就能拿到整本書的完整試讀。團隊一起看讀者在哪裡投入、在哪裡溜走,以及第一件該修的事。
「我是個容易分心、也很難進入寫作心流的人。在用 Slima 之前,若我有兩個不同想法的劇情發展,就要自己做兩個版本的管理,光是切換版本這件事,就會打斷我好不容易進入的心流;用了之後,我可以安心直接修改,等寫作告一段落,再把需要的版本抓出來就好。」